On Mar 11, 2013, at 6:55 PM, Bill Meier 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.
>
Hi Bill,
I do not have an HL7 director and that is not needed here anyway. I am just using that directors that are on by default, so it is out of box plain vanilla.
That was also my thought that WireShark should show me everything that is on the wire, independently from the client program bug. That is another issue that because of the bug the client program is unable to process it and writes error messages to the error table. So back to the issue related to WireShark, then the question is, is there any network setting either on a Cisco switch or on a Cisco router that would fragment messages longer than 32K and drop the fragment.
My guess is at this point that there are two independent processes or settings that appear as fragmenting the message. One of course is the bug in the client program, a buffer is set at 32K long, so it cannot take messages which are longer than 32 K. But this is not the original problem, it is just a consequence. I think the original problem is that the message comes as fragmented already on the wire. Where the fragmentation starts I have no die, but my guess would be a Cisco switch, because if we take one character off from a fragmented message and resend it to our test system it is processed fine. If we now add one character back to the message and send it to the test system it complains. If course it is possible that in this second route there is no network problem only the hit on the bug.
Later on I try to reload the capture file and attach some screenshots. Unfortunately the messages contain PHI, so I cannot put them up on a public server.
I also will try to hunt down the fragments if let say they are somehow and somewhat delayed, that is if they are a few or few hundred frames later in the capture.
Thanks ahead,
János
