Problem with byte-swapped IP addresses

[Carter Bullard]

The weirdest scenario that I can think of, is that under high load, the pf-ring
could be passing up the same packet twice.  we modify it, on the first pass, and
so we get a modified packet as a new packet, the second time.

Is this possible?

Carter


On Mar 7, 2010, at 10:29 PM, Peter Van Epp wrote:

> On Sun, Mar 07, 2010 at 01:43:44PM +0100, Martijn van Oosterhout wrote:
>> On Sat, Mar 6, 2010 at 4:19 AM, Peter Van Epp <vanepp at sfu.ca> wrote:
>>>        While it would be nice to blame pcap (and pf-ring has its own version
>>> of pcap) I think its unlikely, as pcap doesn't care about line order it just
>>> copies the buffer it got from the interface. Argus is the one that cares about
>>> host order and thus does the htn type macros (or in this case perhaps doesn't
>>> :-). That said I would have thought the argus file output should just be a
>>> copy of the input buffer before any of the conversions are done. Can you get
>>> am independent capture (tcpdump, a sniffer, something like that) in parallel
>>> on the argus input interface so you could see what the wire thinks against
>>> what argus writes to the file?  If the dump from the wire is correct and the
>>> output from argus is wrong that narrows the search path considerably as the
>>> switch must be happening early in the path. As noted I still think this is
>>> most likely an argus bug of some kind although its getting odder all the
>>> time :-).
>> 
>> I think I have a parallel capture from tcpdump so tomorrow I'll try to
>> see if I can put them next to eachother.
>> 
>> I agree with that I don't see how the pcap library could be
>> responsible, since it plainly doesn't care about byte order, but in
>> the meantime I have confirmed that if you disable the ring buffer
>> (PCAP_FRAMES=0) the problem goes away (at least over the period we
>> tested, at the very least it hasn't happened yet).
>> 
>> One thought I had: does argus modify the data it receives from
>> libpcap? I don't think so but I thought I'd check. Using the
>> ring-buffer means that the data from PCAP is written to directly by
>> the kernel, whereas normally it's passed back via read(). In that case
>> perhaps there's a race condition where argus is modifying the original
>> data (byte-swapping) after the kernel has written a new packet there.
>> 
>> I'll let you know the results of the tcpdump comparison when I have them.
>> 
>> Thanks for the help.
>> -- 
>> Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/
> 
> 	I suspect we will find this is high load related in which case turning
> off pf-ring likely causes enough packet loss that the load doesn't tickle
> the bug :-). Have you given pf-ring lots of memory for buffers? As I recall 
> (its been a number of years since I last played with pf-ring) we had to boost
> the kernel VM space limit to be able to get a couple of megs of buffer space
> for pf-ring although that may have been a 2.4 series kernel rather than 2.6. 
> 
> Peter Van Epp
> 





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100308/65db3dc9/attachment.bin>