Ethereal-users: Re: [Ethereal-users]TKTP protocol not recognized

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 27 Oct 2003 15:44:30 -0800

On Oct 27, 2003, at 4:56 AM, dirk los wrote:

I didn't know that ethereal is that stateful.

Well, yes, it is - otherwise it can't necessarily know what type of traffic is appearing on a given connection.

Indeed, I am behind a NAT device.  Providing my public address to the
gateway is the only way to get the H.323 VoIP service behind the NAT. So
I seem to have to live with this until a next ethereal might be less
stateful and just interpret the message as it is.

The problem is determining what type of traffic a packet is. TPKT is defined in RFC 1006 to encapsulate ISO 8073 TPDUs - *NOT* Q.931 PDUs, or H.225 PDUs, or H.245 PDUs - so forcing a "decode as" TPKT won't do what you want.

In order to "interpret {a} message as it is", Ethereal has to *know* what it is, and it can do that by

1) looking at some field in the data for the protocol inside which the message is encapsulated (e.g., Ethernet types, IP protocol types, TCP or UDP port numbers, etc.);

	2) knowing that protocol XXX always encapsulates protocol YYY;

	3) looking at the message and trying to guess what it is;

4) inferring from earlier messages for some other protocol what traffic on a given connection, etc. is.

4) is the "stateful" stuff to which you're referring.

Or is this theoretically impossible?

That depends on whether it's possible to determine heuristically whether a packet is an H.225 or H.245 or Q.931 PDU, which would be mechanism 3 above.

Q.931 appears to be possible, so we have a heuristic dissector for it. I don't know enough about H.225 or H.245 to say whether it's possible.

Using mechanism 3 wouldn't make Ethereal "less stateful", it'd just make it possible to use mechanisms other than 4 (if it uses mechanism 3 it might have to use mechanism 4 as well, if *future* packets weren't so easy to recognize as H.225 or H.245 packets).