[Ns-developers] [ns3] Regression in ns-3-dev

[Tom Henderson]

craigdo at ee.washington.edu wrote:
> The failure on darwin-ppc is an endian issue:
> 
> darwin-ppc:~/ns-3-dev/regression nsnam$ od -h traces/udp-echo-0-0.pcap |
> head
> 0000000      a1b2    c3d4    0002    0004    0000    0000    0000    0000
> 0000020      0000    ffff    0000    0001    0000    0002    0000    0000
> 0000040      0000    0036    0000    0036    ffff    ffff    ffff    0000
> 0000060      0000    0001    002e    aaaa    0300    0000    0806    0001
> 0000100      0800    0604    0001    0000    0000    0001    0a01    0101
> 0000120      ffff    ffff    ffff    0a01    0102    0000    0000    0000
> 0000140      0002    0000    0826    0000    0036    0000    0036    ffff
> 0000160      ffff    ffff    0000    0000    0001    002e    aaaa    0300
> 0000200      0000    0806    0001    0800    0604    0001    0000    0000
> 0000220      0001    0a01    0101    ffff    ffff    ffff    0a01    0102
> 
> darwin-ppc:~/ns-3-dev/regression nsnam$ od -h
> ns-3-dev-ref-traces/udp-echo.ref/
> udp-echo-0-0.pcap  | head
> 0000000      d4c3    b2a1    0200    0400    0000    0000    0000    0000
> 0000020      ffff    0000    0100    0000    0200    0000    0000    0000
> 0000040      3600    0000    3600    0000    ffff    ffff    ffff    0000
> 0000060      0000    0001    002e    aaaa    0300    0000    0806    0001
> 0000100      0800    0604    0001    0000    0000    0001    0a01    0101
> 0000120      ffff    ffff    ffff    0a01    0102    0000    0000    0200
> 0000140      0000    2608    0000    3600    0000    3600    0000    ffff
> 0000160      ffff    ffff    0000    0000    0001    002e    aaaa    0300
> 0000200      0000    0806    0001    0800    0604    0001    0000    0000
> 0000220      0001    0a01    0101    ffff    ffff    ffff    0a01    0102
> 
> See the first two shorts in the od output.  This is the
> pcap_hdr_t.magic_number field.
> 
> From libpcap file format doc
> (http://wiki.wireshark.org/Development/LibpcapFileFormat):
> 
> magic_number: used to detect the file format itself and the byte ordering.
> The writing application writes 0xa1b2c3d4 with it's native byte ordering
> format into this field. The reading application will read either 0xa1b2c3d4
> (identical) or 0xd4c3b2a1 (swapped). If the reading application reads the
> swapped 0xd4c3b2a1 value, it knows that all the following fields will have
> to be swapped too. 
> 
> It seems to me that there are two alternatives:  
> 
> 1) We could teach the ns-3 pcap code to write bits out in a standard way
> (Network Byte Order = big endian, perhaps).
> 
> 2) We can keep big and little endian versions of the trace files around and
> compare against whichever is right.

2) seems somewhat cumbersome.  Another option would be to have the 
regression script compare the ascii output of "tcpdump -r <trace>" 
command and let tcpdump handle the endianness issues?  That would put a 
dependency of having tcpdump in the user's path, though.

1) seems like a worthwhile direction to pursue 
(src/common/pcap-writer.cc).  I'll log a bug on it for now.

Tom