From: Guy Harris
| On Sat, May 29, 2004 at 08:38:53PM +0200, metatech wrote:
| > Could you clarify the status of this patch : is it rejected ?
|
| "Pending". Did Olivier Biot respond to the questions you asked
after he
| raised some issues with the patch?
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.
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.
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.
Hope this helps in clarifying!
Regards,
Olivier