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
