Bugzilla – Bug 329
pcap files generated in native win32 (mingw) are always corrupt
Last modified: 2009-01-16 03:08:51 UTC
Like the summary says.
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
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.
both of these bytes have been added just before the src and dst fields of the ip header addresses.
but I can't figure out how this could happen from the current code. will try to reproduce later with a windows install.
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. """
(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 ?
changeset 03dc74055f8a