On Thu, 3 Jul 2003, Jeff Morriss 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.
Yes, I agree.
> > 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.)
No, I was thinking of how a tool like Ethereal would be able to figure out
how to dissect the PDUs in a packet that simply contained SMB PDUs.
It seems that we have two alternatives:
1. Unique protocol IDs for each and every protocol
2. Some sort of path to the protocol.
Perhaps there are other approaches that I have not though of.
I think we should thrash this out some more, because it is worthwhile to
get it [close-to] right.
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
