On Fri, Nov 12, 2010 at 2:15 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> Define "materialize". Wireshark is capable of reading and writing pcap-ng files, and has been capable of that for a while; libpcap 1.1.x can also read pcap-ng files that have only one link-layer type and snapshot length (because no API changes have been made to expose the additional capabilities). Wireshark currently doesn't support the per-packet option fields, so it doesn't read the comments for the packet; if it were extended to support that, it could be used (although programs using libpcap to process packets wouldn't see the comments - and, unless they include their own pcap-ng code, they wouldn't be able to write out the files as pcap-ng files, so the comments and other options would be lost).
This looks somewhat better than the picture I got from the wiki page
(http://wiki.wireshark.org/Development/PcapNg) which seemed to
indicate that only Ethernet link type would be supported. Though, the
per-packet opt_comment part would likely be the area that I would
really need to get shown in Wireshark.. And with that, the
"materialize" would probably be defined as "getting per-packet
opt_comment showing up in Wireshark" in near future. Looks like I'll
need to take a closer look at the current implementation then.
This would likely not be suitable for the
annotation-as-a-bogus-frame-from-kernel part, so the question about
radiotap/IEEE 802.11 frame extension with vendor-specific contents
(OUI/subtype used) would probably still be something that would be
nice to get resolved. For expert info, I'd guess it could be encoded
somehow in opt_comment.
- Jouni
