[Oisf-devel] <Error> (ReceivePfring) -- [ERRCODE: SC_ERR_PF_RING_RECV(31)] - pfring_recv error -1

[Will Metcalf]

> I've been running with 1520 today, and still get those sorts of errors
> with both native PF_RING (threads=1) and PF_RING-enabled libpcap.

Yes well there could be other reasons for this :D. I just verified
that the logic for dealing with snaplen on a fully loaded frame is
indeed broken,you end up getting the NULL byte as the last byte in the
payload, so you might still be getting app layer parsing errors, but I
bet you are getting much fewer of them, as cutting off the last byte
in the payload means checksum validation fails.

Regards,

Will

On Thu, Aug 4, 2011 at 11:25 AM, Chris Wakelin
<c.d.wakelin at reading.ac.uk> wrote:
> I've been running with 1520 today, and still get those sorts of errors
> with both native PF_RING (threads=1) and PF_RING-enabled libpcap.
>
> stats.log shows decoder.max_pkt_size = 1518 in both cases. (I'm now
> using PF_RING 4.7.2 and took vlan_id out of the packet hash to cope with
> our one-sided VLAN tags).
>
> Best Wishes,
> Chris
>
> On 04/08/11 16:54, Will Metcalf wrote:
>> Yes or as Peter mentioned VLAN headers... 1518 seems like a better
>> default imho taking these two things into account.  Or heck what about
>> 1522 to account for both 802.1q headers and FCS?
>>
>> Regards,
>>
>> Will
>>
>
> --
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
> Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>