Grant Williams wrote:
I just wanted to state that I believe that although some dissectors may
decode packets as something they are not, as long as the user has some
control over this behaviour that it isn't all that bad, as usually you have
some idea of what is meant to be going on. Eg if you are expecting RTP
streams you would like to see them as RTP, and if you are not expecting
them, and they do not decode correctly, then turn off the dissector.
Agreed, but in case you have a capture with two protocols where the
corresponding dissectors interfer with each other (i.e. you can only dissect
one protocol at a time, which is what the original thread is about), then
it gets annoying, IMHO. A preference setting which enables me to dissect
both protocols at once is clearly desirable, so *please* check this patch in.
OTOH, in the case of SNMP, one may even argue that we should remove the
conversation code entirely (or default the preference setting to false),
since at least RFC1157 (section 4.1) demands:
If, as a result of
this processing, a message is returned then the source
transport address that the response message is sent from
shall be identical to the destination transport address
that the original request message was sent to.
Users would still have the freedom to use "Decode As" to dissect packets
not using port 161/162 as SNMP.
I'd love to see this issue addressed before 0.10.4.
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)