2009/5/28 Bryant Eastham <beastham@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Comments inline. Sorry, outlook isn't the greatest.
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Guy Harris
Sent: Wednesday, May 27, 2009 9:05 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Question about port registrations
On May 27, 2009, at 7:20 PM,
Martin Visser wrote:
> So for Bryant's question is the issue that his customer didn't
> capture the initial SYN/SYN-ACK handshake, and hence Wireshark
> didn't have opportunity to remember which was the initial
> destination port (and hence "server" port and the one the one he
> would be interested in dissecting for?
At least one issue is that Wireshark *doesn't* remember the initial
destination port, and just tries the lower-numbered port first, so the
initial SYN or SYN+ACK won't help. Whether the capture had the
initial SYN or SYN+ACK is another matter.
[Bryant Eastham] This seems like bad behavior. I can
understand that
[Bryant Eastham] not all protocols define session startup, but in
[Bryant Eastham] the case of TCP/IP wouldn't it be better (if
[Bryant Eastham] available) to use the direction of the session
[Bryant Eastham] to prioritize the dissector choice?
[Bryant Eastham] Maybe the dissector that is making the call to
[Bryant Eastham] the sub-dissector through the lookup table should
[Bryant Eastham] indicate the "direction", which could guide the
[Bryant Eastham] choice?
How would you suggest that the direction would be known to
any dissector in the event that the capture you have at hand is not including
the part where then SYN packets are exchanged in this case?
Even if the Wireshark framework would change according to
your suggestion where the TCP dissector would indicate for sub-dissectors the
"direction" of the communication, you would still have to be able to
handle the case in the sub-dissector when the TCP dissector does not have a
clue (since it never saw the SYN packets being exchanged). This would then have
to be part of the possible input to the sub-dissector (direction is either
"to client"/"to server"/"unknown").
Hence back to square one again.
Personnally I have handled the same type of situation when
it has struck me by one out of two choices:
1. Disable dissection for all protocols, then enable
dissection for the ones you are really interested in (for instance TCP and your
own in this case).
2. Make sure your sub-dissector handles heuristics and
enable heuristics in the TCP dissector, that way your sub-dissector should be
able to take ownership of the session in question.
Best regards, Peter
[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).
[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”,
[Bryant Eastham] or whether it is possible to distinguish from a
single packet whether the session is
[Bryant Eastham] beginning. That logic would be required in the
conversation initialization code.
