On 10 June 2016 at 13:19, Paul Offord <[email protected]> wrote:
> I’m writing some code that produces PCAP-NG files that I subsequently read > with Wireshark. However, WS throws an error when I open the resulting file > and it’s complaining about there not being enough data left in an Enhanced > Packet Block to satisfy the stated size of an option. I’ve think I know > what’s wrong but it’s led me to a fundamental question. > > > > In the documentation in > https://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html section 3.3 > the diagram shows that a variable length Options block can exist at the end > of an Enhanced Packet Block. I have assumed that if I don’t want to > specify options I have to add an Option Code opt_endofopt and Option Length > of zero at the point, which comes to four bytes 0x00000000. > > That's obsolete documentation, try here: https://github.com/pcapng/pcapng I've no idea if that will explain the issue, but at least you'll then be using the same spec as the Wireshark code. > > However, I’ve noticed that Wireshark generated traces don’t seem to do > this. All the examples I have looked at have two bytes of zeros, but this > happens to align the end of the packet data on a 32-bit boundary and so I’m > not sure if that’s the reason for the two bytes. > > > > · If I don’t want to add options to a packet, what should I add > just prior to the trailing Block Total Length value? > > · Is this a Wireshark bug (writing incorrect format PCAP-NG files)? > > > > Thanks and regards…Paul > > > > -- Graham Bloice
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
