On May 28, 2009, at 6:47 AM, Bryant Eastham wrote:
[Bryant Eastham] Sorry, my bad. I had assumed (not having looked at
the code) that the subdissector choice
[Bryant Eastham] was managed by Wireshark. Looking at the TCP
implementation, I now see the code that
[Bryant Eastham] disagree with (although the logic of the decision
is stated clearly in the comment).
The logic of the decision is correct - in the general case it would
make no sense to, for example, try the source port first and the
destination port second for each packet, as that could mean that one
direction would be dissected as one protocol and the other direction
dissected as another protocol.
*Adding* code to remember the two ports on an initial SYN or SYN+ACK
and to, once a dissector is found, make that the dissector for the
connection (so that the decision isn't made again for subsequent
packets, unless something explicitly changes the dissector - e.g., for
SMTP turning into SMTP-over-TLS), would make sense.
[Bryant Eastham] I also note that the dissector is already keeping a
conversation per session (as best
[Bryant Eastham] it can), and so the recommendation would be to keep
track of the direction if it is known,
[Bryant Eastham] and to use that direction to modify the port choice
to prefer the “server” port. It seems
[Bryant Eastham] that the decision need only be made once, when the
session conversation data
[Bryant Eastham] structure is created. The conversation would then
contain the port that will be used
[Bryant Eastham] for all subdissector calls in that session. If the
first packet in the session does not
[Bryant Eastham] indicate direction then the existing “lower port”
logic would be used.
[Bryant Eastham] Not knowing the details of TCP (thankfully) the
only part I would be unclear on is
[Bryant Eastham] whether from a single packet you can make any
determination as to the “direction”,
In the general case, no. For a SYN or SYN+ACK packet, yes.
[Bryant Eastham] or whether it is possible to distinguish from a
single packet whether the session is
[Bryant Eastham] beginning.
Yes - a packet with SYN set and ACK not set is the very first packet
of the session, and a packet with SYN and ACK set is the second packet
of the session, a reply to the first packet. See section 3.4,
"Establishing a connection", of RFC 793.
