Comments inline. Sorry, outlook isn't the greatest.
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[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?
> Maybe in this case we could have some other heuristic. One way would
> be to try both the source and destination port registered dissectors
> and see which one seems give a better result (maybe measured by the
> result in the Information field).
Unfortunately, "trying" a dissector means potentially changing state,
so it's not as if you can necessarily try two dissectors and see which
does a "better" job (leaving aside the difficulty of determining
"better" by the Information field).
That sounds more like a "new-style" dissector, which can give up on a
packet before it's changed any state.
> Another way (and less reliable) might be based around the fact that
> clients are more likely to send zero-length ACK responses (but I
> might be wrong in that)
Or less likely to send large amounts of data (which could be the same
thing), although that's not necessarily guaranteed for, for example,
remote file system protocols, in a case where you have a client with
lots of memory to cache data and is doing a lot of reading of the same
files (and caching the data after the first read) and writing of files
(which eventually go over the wire).
________________________________________________________________________
___
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe