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: Jeff Morriss <morriss@xxxxxxxxx>
Date: Mon, 07 Jul 2003 16:56:17 -0400

John McDermott wrote:

Richard Sharpe wrote:


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.



I guess my first question is how would these get generated? Are you looking at having a program spew them out for debugging? If you are not going to have some SMB and some NFS and some Telnet and some ... Could we not modify the "decode as" mechanism to just pass the PDUs on to dissectors? What changes would we have to make in the wiretap/libpcap layer?

In my case, yes, it's for debugging. In my case I get access to MTP2 or MTP3 and higher when I receive the message. There was never any ethernet, IP, or SCTP involved.

I don't particularly like the "Decode As" idea: I'd rather have the files self-describing (e.g., so if someone sends me a file that contains SCCP I don't want them to have to also tell me that it's SCCP--computers are supposed to make our lives easier, aren't they? ;-) ).

Just thinking out loud (and maybe talking out my whatever) isn't some sort of layer necessary to say, "here comes 150 bytes of SMB" so we could get accurate packet boundries?

Good point. Especially since some protocols (MTP3) don't have length indicators in them... (MTP2 does but it's only 6 bits long: anything over 63 octets in length has a length of "63".)


Another reason to have one DLT_ value and a "fake link" layer would be if we want to support multiple protocols in one file (e.g., an SCCP packet followed by an MTP3 packet followed by another SCCP packet).

If you are debugging, couldn't you print out fake headers, too?

I had considered writing fake headers, but in my case there never was any ethernet/IP/SCTP under the SS7 packets, so it feels really ugly to me. (What do I put for a source-IP address? 0.0.0.0? Blech...)