Problem with byte-swapped IP addresses

[Peter Van Epp]

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