|
Bugzilla – Full Text Bug Listing |
| Summary: | pcap files generated in native win32 (mingw) are always corrupt | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | core | Assignee: | 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
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 |