Hi, I am trying to view optional comment field present in pcapng EnhancedPacketBlocks, but wireshark is not displaying that. I see a bug (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6229) has been fixed related to this in wireshark 1.6.2 release and i am using 1.6.3. Do i need to do something more. Plz help. Thanks, Ambika asked 05 Jan '12, 22:55 ambika edited 06 Jan '12, 02:00 Guy Harris ♦♦ |
One Answer:
Yes. You need to modify the API that Wireshark's Wiretap library (the source to it is in the Then you need to modify the Wiretap module for reading pcap-NG files ( Then you need to modify Wireshark to do something useful with comment fields it reads (including figuring out what "something useful" would be, e.g. putting it into the "Frame" section of the packet details, or having them pop up as tooltips in the packet list; here's how Network Monitor handles frame comments). Or, alternatively, you have to wait for somebody else to get around to doing it. I.e., that's a feature that hasn't been implemented in Wireshark. The bug in question wasn't that comments weren't displayed, the bug was that if a frame had a comment Wireshark didn't properly return the packet data in the frame, so that Wireshark couldn't even show the frame's data correctly. That means that all the fix does is allow you to read the packets in a pcap-NG file with fame comments; it doesn't mean that anything useful is done with the frame comments. Bug 3096 is the enhancement request for adding that feature. answered 06 Jan '12, 02:10 Guy Harris ♦♦ edited 06 Jan '12, 02:15 |
I've been playing around with this lately. I do have something very rough (the GUI parts look horrible ;). Only for pcapng, not taking into account utf8,16, ...
I am planning to create a first patch before beginning of Feb (meeting at Fosdem) so that people can comment on it, especially on the way the data is handled internally. Basically, the idea is to add a comment field to struct wtap and to struct frame_data.
I'm inclined to reduce the number of fields in
struct frame_data
over time, as there's astruct frame_data
for every packet, and that can add up to a lot of memory. Most frames probably won't have comments in a large capture file; perhaps a separate sparse data structure using the frame number as a key and the comment(s) as a value would be better.