Bug #4925

SCTP multihoming / ABORT between osmo-msc and osmo-stp

Added by laforge 2 months ago. Updated about 2 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


Test scenario
  • Debian 10 (buster) on x86_64
  • osmocom:network:nightly package feed of today (2020-12-28)
  • machine with a variety of network interfaces with various IPv4 and IPv6 addresses
  • osmo-stp and osmo-msc on that machine
  • default configuration, where osmo-msc will establish AoIP (BSSMAP/SCCP/M3UA) to the STP
What I'm observing is that
  • the INIT chunk from MSC to STP doesn't contain additional IP addresses for the SCTP client side
  • the INIT_ACK chunk from STP to MSC contains all of the local IPv4 and IPv6 addresses

The SCTP conenction is established normally between [::1]:37826 and [::1]:2905, with INIT/INIT_ACK/COOKIE_ECHO/COOKIE_ACK/HEARTBEAAT/HEARBEAT_ACK.

However, after some time the MSC side socket is sending HEARTBEAT chunks both from its auxiliary a ddresses and to auxiliary addresses, e.g.
  • ->
  • ->
  • ->

IMHO, All of those should never be sent, as the MSC-side socket doesn't advertise any auxiliary IP addresses in its INIT chunk. So the STP-side socket rightfully rejects those with ABORT chunks.

This behavior seems to continue throughout the connection lifetime.

I'm attaching a related pcap file.

sctp-heartbeat-abort.pcap sctp-heartbeat-abort.pcap 159 KB laforge, 12/28/2020 04:55 PM

Related issues

Related to OsmoHNBGW - Bug #4926: nano3G disconnect / reconnect cycle with SCTP multi-homingNew12/28/2020


#1 Updated by laforge 2 months ago

  • Related to Bug #4926: nano3G disconnect / reconnect cycle with SCTP multi-homing added

#2 Updated by pespin about 2 months ago

This looks like a variant of the bug I reported here:

Since the client (MSC) is bound to ::1 -> ::1, it shouldn't be using other source addresses.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)