Given your input I can live with the patch. Guy, what's your view?
Maybe we can check it in and see if it breaks something (which it
shouldn't).
Regards,
Olivier
----- Original Message -----
From: metatech
| 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
|
| _______________________________________________
| Ethereal-dev mailing list
| Ethereal-dev@xxxxxxxxxxxx
| http://www.ethereal.com/mailman/listinfo/ethereal-dev
|
