 | 1 | initial version |
The list of options for the Enhanced Packet Block says that the length of the epb_queue option - i.e., the packet block queue option - is 4 bytes.
That's also what the pull request to add that option (and two other options) to the pcapng spec said the length of the queue option is.
And it's what the code to read and write those options, as submitted by the same person who submitted the change to the specification, expects when reading and writes when writing.
So the first thing to do is to find out what program wrote that file, and find out who maintains that program, and tell them that the packet block queue option length should be 4, not 8, and point them to the section of the pcapng specification I mentioned in the first paragraph. If you don't know what program it is, but you can make either the entire capture file or the first 1024 bytes of the capture file available to us (which probably means making it public!), we might be able to determine the program (if it's kind enough to write out an shb_userappl string option in the Section Header Block indicating what program it was).
What Wireshark could do is simply ignore the queue option, for now; that's what it does for some other incorrectly-sized options. Ideally, however, there should be a way for Wireshark's file-reading code to report warnings - or recoverable errors - i.e. cases where the file is not a valid pcapng file but where we can recover by just discarding the bad part. Those might pop up in a list when Wireshark finishes reading the file, or in a list of warnings when TShark or other tools finish reading the file (so that they're not lost in the middle of normal output).
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
