Wireshark · Ethereal-dev: Re: [Ethereal-dev] Re: [PATCH] Order of subdissectors : suggestion of a trick

[metatech <metatech@xxxxxxxxxxxxx>]

Olivier,

Here are the answers to your objections regarding this patch (see below) :

> | On Sat, May 29, 2004 at 08:38:53PM +0200, metatech wrote:
> Not sure if I provided answers to *all* questions, so here are my
> comments and answers on your questions:
>
> 1. Your fix will work for all TCP conversations captured
>    from the initial SYN onwards. Others won't work.
>    (You stated this in your remarks too.)
>
> This is an issue as it breaks dissection of the "cpature-after-start"
> TCP connections.

It does not break the dissection more than before.
If the TCP SYN was not part of the conversation, the normal logic applies : 
the lowest port is tried (as mentioned in my post of the 16/5).  In other 
words, if the SYN was not seen in the conversation, the behaviour that is 
currently implemented in Ethereal is applied.
Therefore, the situation stays exactly the same as before for the 
"capture-after-start" cases.

> 2. The patch also assumes that a TCP Server always hosts
>    an upper-layer server too, which is not always true:
>    the OTA-HTTP push mechanism defined in WAP (now OMA)
>    provides a scenario where a TCP Server hosts an HTTP
>    Client :)
>
> Unfortunately I am not able to present you a sample capture of this.
> However I can explain how it works.
>
> There is a scenario in OTA-HTTP (aka HTTP push) where the Terminal
> connects to the Push Proxy Gateway (PPG) with a TCP connection. In
> order to do so, the Terminal's TCP socket picks a "dynamic" port and
> the PPG's TCP socket is known to the Terminal (TCP server socket as we
> know it from say an HTTP server in the Internet where the server port
> would typically be 80 for HTTP traffic). At the TCP layer, you'd see:
>
>     1. Terminal -> PPG: TCP SYN
>     2. PPG -> Terminal: TCP SYN, ACK
>     3. Terminal -> PPG: TCP ACK
>
> Now the TCP connection is established. The HTTP Push delivery however
> *implies* that the PPG sends the push as a body of an HTTP POST
> request ***towards the Terminal***. This means that although the
> Terminal requested a TCP connection to the PPG, it is the PPG that
> will send the first data over the socket pair:
>
>     4. PPG -> Terminal: HTTP POST /wappush HTTP/1.1
>     5. Terminal -> PPG: HTTP/1.1 200 OK
>                         TCP ACK
>     6. PPG -> Terminal: TCP ACK
>
> Now the TCP connection can be torn down, or some other OTA-HTTP
> transactions can be performed.

I do not see how the OTA-HTTP protocol is different at the TCP layer than 
"regular" protocols (HTTP, POP3, ...).
You say that the PPG listens on a well known port, and that the terminal 
port is dynamic (not fixed).

Let us take an example :
PPG listens on port 4035. (WAP Push OTA-HTTP port taken from 
http://www.iana.org/assignments/port-numbers)
Terminal port chosen dynamically is 1080 (for instance).

The dissector that should be called by the TCP dissector is the WAP 
dissector (not the SOCKS port registered for port 1080).
For that the OTA-HTTP dissector needs to register the port 4035 in the 
"tcp.port" table.

The logic of the patch is the following :

1. If the SYN without ACK sent by the Terminal was part the conversation, 
the TCP destination port of that packet will be flagged as server port.  In 
this case the port 4035 will be used to look up in the "tcp.port" 
table.  The dissector called will be WAP Push OTA-HTTP.

2. If the SYN without ACK sent by the Terminal was NOT part the 
conversation, the lowest port (1080) will be used to look up in the 
"tcp.port" table.  The dissector called will be SOCKS.

It does NOT matter which sides sends application-level data first : the 
patch only considers the three-way handshake of the TCP protocol establishment.

I think the patch makes the detection more reliable when enough information 
is available (carried by the SYN), otherwise it falls back to the "old 
behaviour".

> 3. I'd prefer having the possibility to flag troublesome
>    conversations and let the end-user provide the correct
>    dissection for those odd cases. This however still
>    requires some thinking :)
>
> And I still did not come up with a ready solution here. The idea is
> that *if* more than one dissection is possible for the given TCP
> conversation, then we should leave it to the end-user to make the
> correct decision... unless we have a considerably safe method which
> will not match "false positives" and/or "true negatives".
>
> My motivation for this is that Ethereal cannot know everything, but
> that it will try hard to apply its logic on the captured packets so
> that an end-user is almost certainly looking at the correct
> dissection. This however is not 100% error-proof.

I cannot think of any cases of troublesome conversations (for which the 
trouble is "introduced" by the patch of course), i.e. I do not see any 
situation for which the situation WITH the patch is worse the situation is 
worse than the situation WITHOUT the patch.

If I misunderstood in any way the WAP protocol, do not hesitate to give me 
more information so that I can investigate in order to make the Ethereal 
port detection the most reliable as possible :-)

Best regards,

metatech