http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1392
ulf.lamping@xxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|packet protocol |RPC portmap classification
|classification switched on |switched to TCP after
|the fly |filtering
------- Comment #2 from ulf.lamping@xxxxxx 2007-02-24 14:16 GMT -------
First some background:
The packets are dissected sequentially from the first to the last. Context
information (e.g. infos about TCP segmentation) is build internally while
dissecting the packets. So a dissector will know less initially dissecting the
first packets than later on.
If you apply a filter, the packets will be redissected - but the context
information is already available from dissecting the first packet.
So yes, if you redissect the packets a dissector may display different things
than in the first run - that's not a bug, that's a feature ;-)
However, the dissector should display more detailed - not less as in your case
- and that's a bug ;-)
About your capture:
Packet #6 is initially dissected as:
"Portmap V2 DUMP Call"
This is the last (only) fragment of an ONC RPC call.
Although this is the last (only) fragment, the packet content itself is NOT
dissected - which is probably the root of the problem.
After filtering (e.g. Follow TCP Stream), the same packet is dissected as:
"TCP 3289 > 111 [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=44 ..."
Interestingly, the packet content is still marked as "Remote Procedure Call
Fragment" - without further dissection of the content.
So in the end, this seems to be a problem in the RPC portmap dissection Dump
call problem, but I'm not an ONC RPC expert. It just results in less detailed
dissection the second run :-(
I've changed the summary accordingly, but can't help your here ...
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
