When having one Diameter message spanned in two different TCP packets (TCP is used as Diameter transport protocol), wireshark sometimes is not able to reassemble properly the Diameter messages.
We have seen the following situations: 1) The payload in the TCP message is not starting as a Diamter message (probably wireshark does not understand the Diameter version and the Diameter message length are coming). In this situation, wireshark shows the Diameter message as a CONTINUATION of the previous ones. 2) The payload in the TCP message seems to be starting as a Diameter message (probably wireshark understands a Diameter version and a valid message length is coming), but the truth is it is the continuation of a Diameter message which was sent in the previous TCP packet. In this situation, wireshark shows the Diameter message is containing a unknwon command code containing a malformed Diameter message.
This is usually seen when a packet is lost or at the beginning of the trace. Once the TCP payload is starting with a valid Diameter message (with its Diameter version, length, and valid command code) wireshark is decoding the messages properly, until a new packet is lost.
In the end, it seems a system is sending invalid Diameter messages when it is not.
Have you already seen this problem? Do you know if that might be related to how wireshark reassembles Diameter messages?
By the way, both TCP (Allow subdisectors to reassemble TCP streams) and Diameter (Reassemble Diameter messages spanning multiple TCP segments) options to reassemble Diameter/TCP messages are set.
asked 27 Mar '14, 11:29
From what I understand of your question (hint: a publicly posted capture somewhere helps tremendously) you are expecting the Diameter dissector to be able to correctly reassemble and dissect messages where some fragment of the message is missing?
I'm not at all familiar with Diameter but in general this isn't going to happen for any protocol as each message fragment will contain vital information for the reassembly and if any is missing then reassembly will be at best broken, and at worst the dissector will complain about a malformed (incomplete) message.
This situation will especially apply for protocols running over stream based (i.e. no message boundaries) transport protocols such as tcp as the application protocol doesn't have any idea of what transport fragmentation may be taking place so can't ensure a viable application pdu is in each transport layer fragment.
answered 28 Mar '14, 03:25