Problem with byte-swapped IP addresses

[Peter Van Epp]

On Fri, Mar 05, 2010 at 09:31:57AM +0100, Martijn van Oosterhout wrote:
> On Thu, Mar 4, 2010 at 7:59 PM, Peter Van Epp <vanepp at sfu.ca> wrote:
> > On Thu, Mar 04, 2010 at 05:34:13PM +0100, Martijn van Oosterhout wrote:
> >> Hi,
> >>
> >> (argus 3.0.0, but it also happens with 3.0.3.2)
> >>
> >> I'm having a problem with IP addresses being byte-swapped in the argus
> >> output, like so:
> >
> >        I assume this is an Intel (or other bigendian) machine?
> 
> Yes, it's Intel.
> 
> > It may be profitable to try and capture the pcap input
> > files that argus sees by setting ARGUS_PACKET_CAPTURE_FILE in your argus.conf
> > file although if the pcaps look OK its more likely an argus bug somewhere I
> > think.
> 
> Thanks! I didn't know argus had this feature, but it certainly
> narrowed down the problem. Because the pcap file generated by argus
> also has these byte-swapped packets.
> 
> # tcpdump -r ~/argus.dump host 98.20.168.192 -s 200 -n -e -v -XX
> 09:04:08.443801 00:06:5b:f4:fb:c7 > 00:06:5b:ed:4d:80, ethertype IPv4
> (0x0800), length 1514: truncated-ip - 54825 bytes missing! (tos 0x0,
> ttl 128, id 10994, offset 512, flags [none], proto TCP (6), length
> 56325, bad cksum 592c (->6e17)!) 18.20.168.192 > 98.20.168.192: tcp
>         0x0000:  0006 5bed 4d80 0006 5bf4 fbc7 0800 4500  ..[.M...[.....E.
>         0x0010:  dc05 2af2 0040 8006 592c 1214 a8c0 6214  ..*.. at ..Y,....b.
>         0x0020:  a8c0 1347 0ca2 06b9 50d2 f1b5 3459 5010  ...G....P...4YP.
>         0x0030:  ffff 3cf8 0000 5445 4d06 0053 5953 5445  ..<...TEM..SYSTE
>         0x0040:  4d07 0078 6c03 0101 0101 0700 786c 0301  M..xl.......xl..
>         0x0050:  0101 0105 00c4 0313 2c0a 0000 0100       ........,.....
> 
> Looking at this it seems there is much more at hand.
> 
> - The length is byte-swapped (dc05 instead of 05dc = 1500)
> - The frag/offset field is byte-swapped (0040 instead of 4000)
> - The addresses are byte-swapped (but we knew that)
> 
> As far as I can tell from the code, argus does no byte-swapping prior
> to dumping the packet, so this is really what argus sees. So it's
> screwing up somewhere after the BPF filter is processed and before
> data gets to argus. Which probably means libpcap/kernel interface.
> Yay! :(
> 
> For reference:
> 
> Kernel: Gentoo 2.6.27-hardened
> pcap-ringbuffer (something from 2006)
> 
> I think the pcap library is a good target.
> 
> Thanks for the help.
> -- 
> Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/

	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 :-). 

Peter Van Epp