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.
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).