This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

SCTP and DIAMETER fragmentation issue

0

There is an inter-dependency between SCTP- and DIAMETER-protocol analysis in case of fragmented packets.

When the preferences for SCTP protocl are set to "Reassemble fragmented SCTP user messages" the packet is shown as "SCTP SACK DATA (Message Fragment).
When the "Reassemble fragmented SCTP user messages" is deactivated in the preferences for SCTP protocl then the packet is shown as DIAMETER message, but it cannot be fully presented. It is truncated with the hint [Unreassembled Packet: DIAMETER].

Of course I would like to have the packet reassembled and correctly presented as DIAMETER packet.

Is this a bug?

asked 13 Feb '14, 03:19

efranz's gravatar image

efranz
21●3●3●6
accept rate: 0%

edited 13 Feb '14, 03:53

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206

One Answer:

1

If you're seeing SCTP SACK DATA (Message Fragment) then you're not looking at the final SCTP segment or if you are looking at the final fragment then Wireshark was, for some reason, not able to reassemble the fragments together (a common cause is one of the fragments is missing).

In other words, if you're looking at a series of fragments with reassembly enabled you should see:

  1. SCTP DATA (Message Fragment)
  2. SCTP DATA (Message Fragment)
  3. DIAMETER [...] - this frame will contain all the payload of frames 1-3 reassembled and dissected as Diameter

It sounds to me like right now you're looking at frame 1 or 2.

answered 13 Feb '14, 13:20

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k●5●72
accept rate: 27%

In my case I only see one SCTP DATA (Message Fragement) packet but no following DIAMETER packet.
The reason for that may be an inconsistency in handling of packet fragmentation which I detected (please confirm). The inconsistency is as follows:

The DATA chunk in the mentioned packet SCTP DATA (Message Fragement) has set the B-Bit set but not the E-Bit, which means it is the first segment of a segmented DATA chunk.
On the other hand the IP header of the same packet has the Don't fragment bit set. Therefore the next DATA chunk is not received.

In Wireshark I can see the packet either as
- SCTP DATA (Message Fragement) if the "Reassemble fragmented SCTP user messages" is set , or
- the identified DIAMETER message if the "Reassemble fragmented SCTP user messages" is not set. In this case the Diameter message is truncated.

Isn't this the explanation of the strange behavior?

(15 Feb '14, 12:52) efranz
1

Hmm, I'm not sure I follow. Are you sure the 2nd fragment was captured? That is, if you remove all display filters can you see the last fragment?

If all the fragments were captured then Wireshark should be able to reassemble them (when the preference is turned on); if not then something weird is going on (possibly a bug). If they weren't all captured then obviously this won't be possible.

The DF bit should be set on all SCTP packets: that's what tells routers to tell the sending SCTP when they encountered an MTU smaller than the size of the message which causes SCTP to lower its path MTU. (OK so when SCTP retransmits the too-big-to-pass message it will do so without the DF bit set but that'll only happen at most a couple of times per assoc.)

(17 Feb '14, 06:57) JeffMorriss ♦