Kernel does not send SCTP_PEER_ADDR_CHANGE notification for blocked peer

Issue

• Kernel does not send SCTP_PEER_ADDR_CHANGE notification for blocked peer
• Kernel does not send transport status change to ULP in assocition setup stage when HB fails
• Our customer configuration uses a multi-homed endpoint at each side of the association. We refer to the local IP address pair as P and S and refer to the remote IP address pair as Pr and Sr.
  • The reproduce scenario is per below:
  • 1) Bring up the SCTP association. After successful initiation, our application shows Pr and Sr as accessible. Traces show successful heart-beating to both peer addresses. This is normal steady-state operation.
  • 2) Block traffic to Sr. We used iptables to cause the blocking. This will cause heart-beating to fail. The kernel provides a notification to the application of Sr being inaccessible.
  • 3) Take down the entire association. This can be done from either side. The kernel notifies the application of inaccessibility of Pr and Sr.
  • 4) Allow the association to re INIT successfully. After the successful cookie exchange, our application marks Pr and Sr as accessible.
  • Issue: After step 4, the traffic to Sr is still blocked in the iptables. Wireshark traces show that no HB/HB_ACK is taking place with Sr. The application does not receive a kernel notification that Sr is inaccessible. Hence, the application believes that Sr is accessible.
  • 5) When remove this block using iptables, HB/HB_ACK works but the application does not receive a kernel notification that Sr is accessible.
  • In step2, if we block/unblock secondary path, Sr accessible/inaccessible notification from kernel works well.