SCTP Init中止正在发生

Question

enter image description here有人可以帮我解决我们服务器端发生的init中止问题。

验证标签始终从发送器端变为0。但是接收器给出了一些随机值的验证标签。

请帮忙。

enter image description here

Answer 1

通常，端点无法建立关联并发送ABORT块作为INIT上的响应。这可能发生在各种情况下（例如，错误配置，当您没有在服务器端为该关联创建端点;或者缺少资源时）。

INIT块有点特殊（携带它的数据包总是在公共头中将验证标记设置为零）。 INIT块也有所谓的启动标记 - 它基本上是一个验证标记，INIT块的发送者希望在该关联范围内收到它将收到的所有数据包。

当ABORT作为对INIT块的响应发送时，它将被发送，并将验证标记设置为INIT的init标记。这正是您在wireshark日志中可以看到的内容。

您的日志文件中似乎很奇怪的是ABORT块的发送方在使用t-bit时不遵循RFC 4960。

RFC 4960, chapter 8.4，子弹3说：

  

如果，无论如何          原因是，INIT无法正常处理，ABORT必须处理          作为响应发送，包的验证标签          包含ABORT块必须是的启动标签          接收到INIT块，并且ABORT块的T位必须是          设置为0，表示未反映验证标记。

在您的情况下，ABORT块的发送方使用init标记作为验证标记（如RFC中所定义），但它也将t-bit设置为1 - 它违反了RFC。由于携带ABORT块的数据包中的t位设置不正确，因此它会阻止INIT的发送方正确处理它。基本上INIT块的发送方无法处理该ABORT。

ABORT的发件人也可以在ABORT块中包含原因代码，以提供有关ABORT原因的更多详细信息。然而，无论出于什么原因，它还没有完成，ABORT的实际原因仍然是个谜。

总结：

1. 很难说为什么ABORT已根据信息发送 提供。如果可以 - 联系您的供应商并建议包括 导致在RFC中定义的ABORT块中的代码以便制作 调试更容易。
2. 我猜你的服务器端没有初始化/配置的东西，这就是没有建立关联的原因。一世 将从检查服务器上的套接字/端点配置开始 侧。
3. 您的关联的服务器端（INIT的接收方/ ABORT的发送方）违反了RFC 4960并且错误地设置了t位。因此 INIT块的发送方无法正确处理ABORT。我会 建议您为服务器端提交错误报告 实施/供应商为了使其得到修复。