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

[Jeff Morriss <morriss@xxxxxxxxx>]

Richard Sharpe wrote:

> 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.

You mean one DLT value for each protocol?  That seems like a lot.

> 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.

By having a "fake link" header that has a "type" (protocol) field you 
can put any protocol in there.  You can even mix protocols:  packet 1 is 
MTP2, packet 2 is SCCP, packet 3 is MTP3, packet 4 is SMB.

Of course, people will have to reserve their fakelink.type's just like 
people reserve DLT_ values.

> > 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 ...

How is that better than just saying:

type=SMB,data="..."?  Why do you need to know what wasn't there above SMB?

Or are you thinking of being able to have IP + SMB but no TCP?  (Which 
seems really complicated to me.)