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?

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

Regards, Martin

[email protected]


On Thu, May 28, 2009 at 8:10 AM, Guy Harris <[email protected]> wrote:

>
> On May 27, 2009, at 2:26 PM, Bryant Eastham wrote:
>
> > Q: Does “dissector_add” differentiate between src and dst port? [I
> > think not, the registration is by name and the dissector (TCP)
> > chooses how to use it.]
>
> No.
>
> > Q: Does wireshark prioritize between built-in vs. plugin dissectors?
> > [I think not.]
>
> No.
>
> > Q: Does wireshark prioritize between dissectors based on matches on
> > src vs. dst port?
>
> No.
>
> It prioritizes based on the port number; lower port numbers are
> preferred to higher port numbers, as they're more likely to be well-
> known ports.
>
> > My fundamental issue is that I would expect that priority be given
> > to the dissector on the *server* (dst) port, as it is the more
> > likely to be standardized vs. ephemeral.
>
> The destination port is the server port only for requests.  If the
> capture includes the entire session, all the way back to the initial
> SYN, and we remember, for each new TCP connection, the source and
> destination ports for the initial SYN, we can determine, for packets
> in that connection, which port is the "client" port and which the
> "server" port.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <[email protected]>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:[email protected]?subject=unsubscribe
>
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to