[Ns-bugs] [Bug 165] New: regression trace endianness

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=165

           Summary: regression trace endianness
           Product: ns-3
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: sample programs
        AssignedTo: ns-bugs at isi.edu
        ReportedBy: tomh at tomh.org


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.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.