Re: Request for new DLT and LINKTYPE value

["Edgar, Thomas" <thomas.edgar () pnl gov>]

On Apr 13, 2010, at 12:02 PM, Guy Harris wrote:

> Then perhaps the right thing to do is to have *multiple* DLT_/LINKTYPE_ values, one for each protocol, and use the 
> particular protocol's framing mechanism when capturing a particular protocol.  libpcap has an API to select link-layer 
> type headers; it was originally introduced to support a BSD BPF mechanism that let 802.11 devices default to 
> fake-Ethernet headers for backwards compatibility and allow 802.11-knowledgable applications select 802.11 headers, 
> but it's also used with, for example, Endace DAG serial-line cards to select the link-layer type being used with those 
> cards, as well as to handle Cisco's cable modem head-end systems which can spew out DOCSIS frames inside low-level 
> Ethernet framing for tracing.
>
> That API is supported by tcpdump and Wireshark/TShark, so if the code to capture those link-layer types also supports 
> it, it should Just Work.

I am open to the possibility of going forward with that approach. Just to clarify, does this work by the user 
preselecting the framing mechanism before the capture is started?  For instance, I would have to know that DNP3 is 
being communicated before I start the capture?

With the timing method I am using I was going for a method to capture anything from a COM port and then allow the 
parsing mechanism (like the heuristic dissectors in Wireshark) to determine what protocol is actually present.  I am 
going for a more hands off user experience than requiring them to decide beforehand which protocol to capture.  What do 
you think?



-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.