On 2008-03-26, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> Grant Edwards wrote:
>> I'm tracing data in a TCP connection between two devices, and
>> about half way through the trace, wireshark stops displaying
>> packet info and just shows [TCP segment of a reassembled PDU].
>>
>> It's _not_ a "TCP segment of a reassembled PDU". It's just a
>> stream of bytes.
>
> To what does "it" refer?
The TCP byte stream for which packets are being displayed as
"TCP segment of a reassembled PDU".
> The entire TCP connection is the stream of bytes; individual
> packets are what are reported as TCP segments of a
> reassembled PDU.
They're not parts of a PDU. They're just packets with bytes in
them. There is no protocol associated with the TCP connection.
> The protocol Wireshark thinks the connection is running atop
> TCP is done for which it does reassembly; it appears to think
> that a packet requiring reassembly is in the stream, but, for
> whatever reason - perhaps TCP segments that weren't captured,
> or perhaps a bug - can't finish the reassembly process for
> that packet.
I've narrowed it down more. Wireshark appears to get confused
when it sees a DCE RPC packet that's not part of the TCP
stream. Before that DCE RPC packet, all of the packets in the
TCP stream in question are displayed properly. After that DCE
RPC packet, they're all displayed as "TCP segment of a
reassembled PDU"
> Try turning the reassembly option off for that protocol (if it
> has such an option in the preferences) or for TCP as a whole.
For what protocol?
> Could you file a bug on this, and attach a capture that shows
> the problem, so, if there *is* a bug (rather than a missing
> packet), we can try to fix it? (Even if there is a missing
> packet, it might be possible to get the reassembly code to
> handle that better.)
After telling wireshark to only capture packets associated with
the TCP port at one end of the TCP connection, the problem goes
away. If I capture all packets to/from the host, then the DCE
RPC packets cause problems with the display of the TCP stream I
care about.
>> I've told wireshard to not decode that TCP stream
>
> What do you mean by "not decode"?
right-click on a packet, select the "decode" entry in the popup
menu, and check the "no decode" radio button for packets in
that TCP stream.
>> but it still refuses to display packet info. I think it's
>> getting confused by packets that aren't part of the TCP stream
>> in question.
>
> If they're present in the capture but not part of the stream,
> that won't affect the reassembly (unless there's a bug in the
> TCP reassembly code).
It sure looks like the unrelated RCP packets are screwing up
the display of the TCP stream. I'll see if I can get a short
capture that demonstrates the problem.
--
Grant Edwards grante Yow! An INK-LING? Sure --
at TAKE one!! Did you BUY any
visi.com COMMUNIST UNIFORMS??
