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
