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.
