Problem with byte-swapped IP addresses

[Martijn van Oosterhout]

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/