Bug 329

Summary: pcap files generated in native win32 (mingw) are always corrupt
Product: ns-3 Reporter: Gustavo J. A. M. Carneiro <gjcarneiro>
Component: coreAssignee: ns-bugs <ns-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: gvubrugier, mathieu.lacage
Priority: P3    
Version: ns-3.2   
Hardware: All   
OS: Windows   
Attachments: sample damaged pcap file
sample damaged pcap file

Description Gustavo J. A. M. Carneiro 2008-09-10 06:05:15 UTC
Like the summary says.
Comment 1 Gustavo J. A. M. Carneiro 2008-09-10 06:13:22 UTC
wireshark says: "The capture file appears to be damaged or corrupt. (pcap: File has 36569088-byte packet, bigger than maximum of 65535)".

There's a bugzilla installation problem and I cannot attach the file.  It is at:

http://telecom.inescporto.pt/~gjc/csma-broadcast-0-0.pcap
Comment 2 Mathieu Lacage 2008-10-20 08:39:03 UTC
I looked at a hex dump of this file. It appears that at least 2 bytes have been inserted in the first packet byte stream:
00000040  00 00 0d 0a 01 00 01 0d  0a 01 00 ff c0 01 00 09  |................|

the two bytes 0x0d should not be here.
Comment 3 Mathieu Lacage 2008-10-20 08:42:50 UTC
both of these bytes have been added just before the src and dst fields of the ip header addresses.
Comment 4 Mathieu Lacage 2008-10-20 08:53:59 UTC
but I can't figure out how this could happen from the current code. will try to reproduce later with a windows install.
Comment 5 Gustavo J. A. M. Carneiro 2008-10-20 13:39:53 UTC
From ascii(7) manpage:

       012   10    0A    LF  ’\n’ (new line)         112   74    4A    J
       013   11    0B    VT  ’\v’ (vertical tab)     113   75    4B    K
       014   12    0C    FF  ’\f’ (form feed)        114   76    4C    L
       015   13    0D    CR  ’\r’ (carriage ret)     115   77    4D    M

So the extra 0x0d's are carriage returns.

I suspect this could be a result of the pcap file being opened in text mode by default, in particular in PcapWriter::Open.  See http://www.cplusplus.com/doc/tutorial/files.html

"""
Text file streams are those where we do not include the ios::binary flag in their opening mode. These files are designed to store text and thus all values that we input or output from/to them can suffer some formatting transformations, which do not necessarily correspond to their literal binary value.
"""
Comment 6 Guillaume Vu-Brugier 2009-01-13 15:39:42 UTC
(In reply to comment #5)
> From ascii(7) manpage:
> 
>        012   10    0A    LF  ’\n’ (new line)         112   74    4A    J
>        013   11    0B    VT  ’\v’ (vertical tab)     113   75    4B    K
>        014   12    0C    FF  ’\f’ (form feed)        114   76    4C    L
>        015   13    0D    CR  ’\r’ (carriage ret)     115   77    4D    M
> 
> So the extra 0x0d's are carriage returns.
> 
> I suspect this could be a result of the pcap file being opened in text mode by
> default, in particular in PcapWriter::Open.  See
> http://www.cplusplus.com/doc/tutorial/files.html
> 
> """
> Text file streams are those where we do not include the ios::binary flag in
> their opening mode. These files are designed to store text and thus all values
> that we input or output from/to them can suffer some formatting
> transformations, which do not necessarily correspond to their literal binary
> value.
> """
> 

You are right, changing the following line in pcap-writer.cc gave me the reference traces using ns-3.2 and MingW:

m_writer->open (name.c_str (),std::ios_base::binary|std::ios_base::out);

I can't provide a patch as I couldn't build a more recent release or ns-3-dev on my machine, but it seems that opening files in binary mode is definitively the solution.

Should ns-3-dev build with MingW ?
Comment 7 Mathieu Lacage 2009-01-16 03:08:51 UTC
changeset 03dc74055f8a