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).