Actions
Bug #4925
openSCTP multihoming / ABORT between osmo-msc and osmo-stp
Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12/28/2020
Due date:
% Done:
0%
Spec Reference:
Description
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
- 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.- 127.0.0.1:37826 -> 127.0.0.1:2905
- 192.168.11.4:37826 -> 192.168.11.4:2905
- 192.168.100.2:37826 -> 192.168.100.2:2905
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.
Files
Related issues
Updated by laforge over 3 years ago
- Related to Bug #4926: nano3G disconnect / reconnect cycle with SCTP multi-homing added
Updated by pespin over 3 years ago
This looks like a variant of the bug I reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=208969
https://www.spinics.net/lists/linux-sctp/msg09739.html
Since the client (MSC) is bound to ::1 -> ::1, it shouldn't be using other source addresses.
Actions