Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Invalid PDU length and TCP reassembly

From: "Abhik Sarkar" <sarkar.abhik@xxxxxxxxx>
Date: Sat, 22 Dec 2007 05:40:04 +0400
Guy,

Firstly, apologies for getting the terminology wrong.

The source of this doubt was indeed the slightly different way in
which the SMPP server I am dealing with and Wireshark deal with the
PDUs in question, but if the specs are to be followed, I guess this is
how it should work. I will think more about it.

Thanks for your explanation.
Abhik.

On Dec 22, 2007 5:02 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Dec 21, 2007, at 4:11 PM, Abhik Sarkar wrote:
>
> > I am facing an issue with dissection of SMPP PDUs with invalid length
> > (though the matter might effect any other dissector which use TCP
> > reassembly too).
>
> ...as well as affecting the receiving SMPP implementation. :-)
>
> > In my test, I send two PDUs in two different TCP frames each of length
> > 40.
>
> The term that's used is "TCP segment".
>
> TCP is a byte-stream protocol, so it doesn't expose a notion of
> "frames" to protocols running atop it - the receiving system should
> operate the same regardless of whether you sent:
>
>        one TCP segment with length 80;
>
>        two TCP segments with length 40;
>
>        80 TCP segments with length 1;
>
> etc..
>
> > However, the PDUs have their PDU length field incorrectly set to
> > 41. With reassembly on in this case, the TCP dissector "steals" one
> > byte from the second frame for the dissection of the first SMPP PDU.
> > However, because the second PDU has now lost the first byte, it is no
> > longer recognized as a valid SMPP PDU and hence is not dissected.
> >
> > With TCP reassembly turned off, the behaviour is that each frame is
> > dissected as an SMPP PDU, but as malformed PDUs.
> >
> > Is this something to be expected,
>
> Yes.  The packets are being interpreted the way the SMPP spec says
> they should be, i.e. there's a 41-byte message split between two TCP
> segments, with the rest of the second TCP segment being the first 39
> bytes of another 41-byte message.
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>