Ethereal-dev: Re: [Ethereal-dev] Support for pure protocol packetswithout underlying protocol
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.)
