Problem with byte-swapped IP addresses

Carter Bullard carter at qosient.com
Sun Mar 7 11:51:48 EST 2010


Argus does modify the packet, but after it has called pcap_dump(),
so if the dump file contains the issue, I wouldn't think its argus's fault.
Unless of course pcap_dump() is somehow just scheduling the buffer
to be written, rather than copying it.   and dumps the buffer after argus
modifies it.

We do reference some variables frequently, so doing ntoh[ls]
in place saves us some cycles.

Do you notice that the flows that are messed up are of a particular
flow type?  arp, esp?

Carter


On Mar 7, 2010, at 7:43 AM, 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/
> 

-------------- 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/20100307/1d24baa7/attachment.bin>


More information about the argus mailing list