CODEWITHSUNDEEP
initabortsctp
Sachin Aravind
Sachin Aravind

Reputation: 170

SCTP Init abort is happening

enter image description hereCan someone please help me to solve the init abort happening from our server side.

Verification tag is always coming as 0 from the transmitter end. But receiver is giving some random value of verification tag.

Please help.

enter image description here

Upvotes: 2

Views: 11971

Answers (1)

Alexander Zinovyev
Alexander Zinovyev

Reputation: 338

In general, it might happen that endpoint is not able to establish association and send ABORT chunk as response on INIT. This might happen in various situation (such as misconfiguration, when you haven't created endpoint on server side for that association; or lack of resources).

INIT chunk is a bit special (packet that carries it always has verification tag set to zero in common header). INIT chunk also has so called initiate tag - it is basically a verification tag that sender of the INIT chunk expect to see in all the packet it will receive in the scope of this association.

When ABORT is sent as a response on INIT chunk, it will be sent with verification tag set to the initiate tag from INIT. That is exactly what you can see in you wireshark log.

What seems to be strange in you log file is that the sender of ABORT chunk does not follow RFC 4960 in respect to using t-bit.

RFC 4960, chapter 8.4, bullet 3 says:

If, for whatever reason, the INIT cannot be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate Tag of the received INIT chunk, and the T bit of the ABORT chunk has to be set to 0, indicating that the Verification Tag is NOT reflected.

In your case the sender of ABORT chunk is using initiate tag as verification tag (as defined in RFC), but it also sets t-bit to 1 - it is a violation of RFC. Since t-bit is set incorrectly in the packet that carries ABORT chunk, it stop the sender of INIT from handing it correctly. Basically the sender of INIT chunk cannot handle that ABORT.

The sender of ABORT could have also include cause code in ABORT chunk to provide more details about reason of ABORT. However for whatever reasons it hasn't been done and the actual reason of ABORT will remain mystery.

In conclusion:

  1. It is hard to say why the ABORT has been sent based on information provided. If you can - contact you vendor and suggest to include cause code in the ABORT chunk as it defined in RFC in order to make debugging easier.
  2. I would guess that something has not been initialized/configured on you server side, that is why the association is not setup up. I would start with checking sockets/endpoint configuration on server side.
  3. The server side of your association (receiver of INIT/sender of ABORT) violates RFC 4960 and set t-bit incorrectly. Because of that the sender of INIT chunk cannot handle ABORT correctly. I would suggest to submit a bug report for your server side implementation/vendor in order get it fixed.

Upvotes: 1

Related Questions