Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Support for pure protocol packetswithout underlying protocol

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Richard Sharpe <rsharpe@xxxxxxxxxxxxxxxxx>
Date: Tue, 1 Jul 2003 14:44:10 -0700 (PDT)
On Tue, 1 Jul 2003, Martin Regner wrote:

> Jeff Morris wrote:
> >What he's got now is a PCAP file format where each packet has a "fake 
> >link" header on it that specifies the lowest-level protocol.  This seems 
> >quite flexible to me--although I suppose that the format of the header 
> >needs to be stable before the file type is allocated.
> >

Hmmm, I am not sure that we should use fake link headers. Rather, we 
should define a separate DLT value for packets that come in without lower 
layer headers.

However, a further issue is that at any future time, people might want to 
create a capture file of only some higher layer PDUs, like, for example 
SMB PDUs without any link layer, network layer or transport layer headers.
 
Having a flexible scheme to deal with this would be useful.

> 
> I have a similar need to get packets of different higher level 
> protocols dissected by Ethereal. In one capture file I want to have 
> packets with several different high level protocols (H.225, H.245, SIP, 
> MTP3, ...), so I have been thinking of using something similar to 
> Navin's "fake link" dissector. 
> However I also want to have possibilities to store some extra data in 
> some cases - so I have been thinking of having
> some kind of Tag/Length/Value scheme for optional data per packet.

I would like to define a DLT-type that allows TLVs or name value pairs as 
its content, where perhaps one of the TLVs or NVPs contains the data.

Perhaps we could include flags like link-hdr=not-present, next-type=IP, 
network-hdr=not-present, next-type=tcp, transport-hdr=not-present, 
next-type=SMB ...

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com