Re: Incorrectly framed messages

[Martin Visser <martinvisser99 () gmail com>]

Janos,

Probably not a bug so much as a design decision. Any program that needs to
allocate space in readiness for accepting a message needs to have an upper
limit. (Programs that don't are susceptible to all sorts of attacks). Of
course you could write in a way that the receiving buffer dynamically
expands.

Also in general the switch/routers in the path only process layer 2 frames
(eg ethernet frames) or IP packets. Hence they might see max of 1518 byte
(or 9K jumbo) ethernet frames, that possibly need to be fragmented so meet
the link MTU size towards the next hop.

Anyway glad, you've identified the issue.

Regards, Martin

MartinVisser99 () gmail com


On 16 March 2013 06:38, Lobb, Janos <janos.lobb () yale edu> wrote:

> Hi Martin,
>
> I rechecked, WS is doing the things right.  Looked the Hex values and I
> could see the handshake - 0d1c0d.  It is the client software bug that
> cannot handle messages longer than 32K.  I captured two such messages,
> their length was above 70K in both cases and they are shown just fine in
> WireShark.
>
> Sorry for the noise.
>
> Thanks a lot,
> János
>
> On Mar 11, 2013, at 8:00 PM, Martin Visser wrote:
>
> > Depending on your capture setup, wireshark should be seeing all of the
> frames on the, regardless of whether they are valid TCP segments or not. As
> Bill has said, unless they are frames broken at the physical level - they
> should be there.
> > If they are shown as "malformed" TCP segments, it sounds like there is
> something up with your TCP stack - is this home-grown or are you just
> putting your app on to a standard Windows/UNIX/Linux stack?
> > You can tell Wireshark to turn off all decoding, for instance TCP, so at
> least you will see the raw frames.
> > You probably need to post a link to a capture to help us understand the
> problem.
> > Regards, Martin
> >
> > MartinVisser99 () gmail com
> >
> >
> > On 12 March 2013 09:55, Bill Meier <wmeier () newsguy com> wrote:
> > On 3/11/2013 3:58 PM, Lobb, Janos wrote:
> > Hi,
> >
> > We have an application that receives TCP messages - HL7 formatted -,
> > into a holding table and processing them later.  We found that
> > because of a bug/limitation in the program it is unable to put
> > together messages that are bigger than 32K.  I understand that the
> > parts above 32K is not shown in the table, but I do not understand
> > why do I not see them in a WS capture.
> >
> > The messages contains different segments, like MSH, IN1, IN2, ROL,
> > etc…    There is a server that sends these messages and there is a
> > client that receives them.  My assumption was that even if the bug is
> > in the client program I still should see the above 32K part of the
> > message in wireshark, but I do not.
> >
> > The message just breaks and the client sends back an ACK message but
> > with some missing IDs, that causes the server to garble up the next
> > message even if that is just a short one.
> >
> > When I look the Expert Info Composite, I see plenty of Malformed
> > messages, about 15,000 from 540,000, but none of them contains the
> > above 32K part of the incorrectly framed messages.
> >
> > Any insight ?  Does Wireshark just drops them ?  If yes, is there a
> > setting to force WS to show them even if they are malformed ?
> >
> > Thanks ahead,
> >
> > János P.S.  Now, this "incorrectly framed message" text is put into
> > the error table by the client program, so it is not necessarily a
> > good labeling of the symptom from the networking point of view.
> >
> >
> >
> > Knowing nothing about the HL7 protocol I'll just make some general
> comments.
> > As far as I know, Wireshark does not have a specific dissector for the
> HL7 protocol (assuming you aren't using some custom version of Wireshark).
> > So: it should be the case that what Wireshark shows is what is on the
> wire. (Assumption: there isn't some low-level ethernet checksum issue or
> similar causes packets to be dropped before thay are captured; this is
> quite unlikely).
> > Wireshark itself wil show all the frames, altho as you note it may have
> difficulty dissecting them completely.
> >
> ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org
> >
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
> >
> ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org
> >
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe