OK, I see what you're saying. I've never traced anything higher than TCP, so I didn't think of that possibility.
You are exactly right in your guess that the SMPP packet shows a "malformed packet" error, so it appears to me like you're on track in your diagnosis of the problem and potential solution as well.
----------------------
Guy Harris 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.
