Hi,
This is one of the reasons I put in the "Disable Protocol..." option
in the packet details context menu. Just to quickly get the annoying
dissectors out of the way :)
Thanx,
Jaap
Sent from my iPhone
On 28 mei 2009, at 13:52, Peter Johansson <[email protected]>
wrote:
2009/5/28 Bryant Eastham <[email protected]>
Comments inline. Sorry, outlook isn't the greatest.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] 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
___________________________________________________________________________
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
