I have created a dissector for meteorological messages under a specific interface designated COREMET which consists of GRIB messages and METAR messages. These messages are sent across TCP/IP from one unix box to another. The GRIB messages are in excess of 1.0 Mbyte and are split over many messages. MTU is around 1500. When everything is correct the dissector works fine. However we have an issue where a packet was lost during transmission. (not sure why yet and I am trying to remotely debug using a wireshark capture). Wireshark marks every packet as [TCP segment of reassmbled PDU]. However the final dissection never occurs, presumably due to the fact that the received bytes do not exceed/equal the required bytes to call the dissector from tcp_dissect_pdus(). I under stand that the message will never decode correctly if it is missing any part however it would be nice to have some sort of indication that the message was caught by never dissected due to the fact that all the data was not received. The next message on that interface is a METAR message which is 420 bytes and will dissect in one go and works fine however there is no indication that the first message failed. I have looked at the pinfo->noreassembly_reason but it contains nothing. short of writing my own tcp_dissect_pdus() which will cope with the missing packet with some sort of timeout has anyone had this problem and found a solution. asked 26 Feb '13, 06:24  spotthemaniac |
One Answer:
"Cope" in what sense? There are at least three reasons why this could be happening:
Fixing the first problem would require that the TCP reassembly code recognize the absence of the segment (it must not, of course, assume that all segments are being delivered in order when doing that!) and, once it either has all the data necessary to complete the packet or has recognized enough absent segments such that, if present, it would have all the data necessary to complete the packet, construct the reassembled packet, perhaps with an indication that some of the data is missing (currently, tvbuffs don't support that). Fixing the second problem has to be done by the dissector - it would have to check whether the header "looks reasonable" and, if not either scan the segment looking for something that "looks reasonable" or not bother trying to dissect the data in the segment as anything other than raw bytes. Fixing the third problem would require some work similar to the work required to fix the first problem. The simplest workaround might be to turn off TCP reassembly - turn off "Allow subdissector to reassemble TCP streams" in the TCP preferences. That will disable reassembly of the GRIB messages, but it will prevent Wireshark from trying to "reassemble" a packet based on, for example, something in the missing segment that's not the beginning of a packet but that Wireshark interprets as a packet. answered 26 Feb '13, 18:29  Guy Harris ♦♦ |
Thank you for the quick answer:
so from analysis of the capture we lost a packet in the middle of the transmission. Dont know why yet. (worrying)
Hence tcp_dissect_pdus never calls my dissector. I assume due to the fact that there is not enough data to fully reconstruct.
five minutes later another message is sent on the same port which is passed straight to the dissector (which decodes fine) as it fits in one packet so I am assuming the tcp_dissect_pdus has a way to differentiate between messages.
I have started looking at the tcp_dissect_pdu code but i am new to some of this. Do you know if wireshark has a structure that holds the partially reconstructed message information?
What I am looking for is a way to interrogate the timestamps of the packet and timeout after x secs and label the first part(packet) of the message as BAD GRIB with only header dissection. (if possible) Regards
Wayne
oh and the get message length code does some form of syntax check before it returns a value from the header of the size of the message. There are specific bytes at specific palces in the header!