Re: New official link-layer type request

[Damir Franusic <damir.franusic () gmail com>]

What works great for me now is the custom DLT and regular PCAP in 
Wireshark. The dissector I wrote
allows me to do a search based on that "metadata" and then use WIreshark 
to for example play RTP CC data
for SIP calls. I am not sure if pcapng is fully supported if i decide to 
implement all that using the options part of Extended Packet Block like 
Guy suggested.



On 5/19/19 1:31 AM, Guy Harris wrote:
> On May 18, 2019, at 3:54 PM, Michael Richardson <mcr () sandelman ca> wrote:
>
> > Guy Harris <gharris () sonic net> wrote:
> > > If we *do* use pcapng, that would mean that:
> > > 1) Wireshark wouldn't be able to read the lawful intercept information
> > > in the files until support for new block types and options are added to
> > > it;
> > Is wireshark modular in how it handles pcapng blocks?
> Somewhat, although it could probably use more work.
>
> > > 2) tcpdump wouldn't be able to read the lawful intercept information in
> > > the files until we add full pcapng support (with new APIs) to libpcap,
> > > including support for the new block types and options, and add support
> > > for the new APIs, and for the new block types and options, to tcpdump;
> > I hope to solve this in 2019/2020.
> Definitely.  The sooner, the better; that would allow capturing on Linux, for example, to supply direction information for *all* 
> link-layer header types (or, at least, for all link-layer header types provided by regular Linux interfaces), as well as providing 
> IDBs for all interfaces when capturing on the "any" device, so that you could see what interface each packet came in on, 
> even if you're reading the file on a machine other than the one on which the capture was done.
>
> > > To be fair, those programs would *also* have to be modified to handle
> > > LINKTYPE_ELEE - and programs that can read pcapng would at least be
> > > able to read the intercepted packets without change, assuming they just
> > > ignore unknown block and option types (which they should do!).
> > :-)
> > My thought is that the regular packets would be in regular blocks, and the
> > extra info would be in the extended blocks.  So without extensions, one can
> > read the packets and do stuff with them, but not know, for instanse, which
> > link they came from, or maybe (I have no idea if this is real meta-info)
> > which warant was used to obtain the data.
> Exactly.
> _______________________________________________
> tcpdump-workers mailing list
> tcpdump-workers () lists tcpdump org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

--
Damir Franusic

email: damir.franusic () gmail com
http://ele2.io/

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers