On Wed, Apr 10, 2002 at 07:05:51PM +0000, J.B. wrote:
> I just figured out a problem (bug?) with the "Follow TCP Stream"
> feature that's been bugging me for a week (no pun intended). It appears
> that if your TCP stream contains bytes that can be misconstrued as a
> signature for a sub-protocol of TCP (like SMPP), and the decoder for
> that protocol is enabled, the "follow TCP stream" skips the packet then
> ends the stream prematurely because the packets are no longer in
> sequence.
It may appear that way from what you saw, but it's not exactly like
that.
If it worked the way you were hypothesizing, that would imply that if
you tried to follow an HTTP connection, you would get nothing, as HTTP
is a sub-protocol of TCP.
However, you *can* follow an HTTP connection, so it can't work the way
you're hypothesizing.
What's probably happening is that...
> In my case, there was a TCP packet in my stream that was decoded as a
> SMPP packet (it just happened to have the right bytes in it). Although
> the stream was far from ended, "follow tcp stream" said the stream was
> done as soon as it hit the packet that it determined was an SMPP packet.
...the SMPP dissector is throwing an exception, because the packet
*isn't* an SMPP packet and doesn't contain as much data as it should
contain were it an SMPP packet, so that the dissection is terminated
before the "follow TCP stream" code is called.
Does the SMPP packet dissector report a "Malformed Packet" or "Short
Frame" error? If so, that's what's happening.
The TCP dissector needs to catch exceptions, if "follow TCP stream" is
being done, and do the TCP stream processing and then re-throw the
exception.
> It would be very nice however if "follow TCP stream" was smart enough
> to notice that this packet was still a TCP packet between the correct
> ports and include it in the stream.
The "follow TCP stream" probably isn't even getting *executed* for that
packet; were it called, it'd note that it's a TCP packet.
> Interestingly enough, the filter generated by
> "follow tcp stream" didn't filter out the alleged SMPP packet, so at
> least that part was working fine.
There's nothing whatsoever surprising about that - the filter generated
by "follow TCP stream" just checks addresses and port numbers, and those
are put into the protocol tree before the sub-disssector is called, so
even if an exception is thrown, those fields still show up in the
protocol tree, so the filter-checking code can still see them.