Bug #5186
closedlocal-ip config parameter can cause unclear behaviour on dual IP stack system
100%
Description
keyphrase from osmo-bsc log for search engines:
DLSS7 ERROR m3ua.c:507 XUA_AS(as-clnt-A-0-m3ua) {AS_DOWN}: Event AS-TRANSFER.req not permitted
In osmo-stp.cfg we have typically have something like:
cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted route-table system listen m3ua 2905 local-ip :: accept-asp-connections dynamic-permitted
This is actually fine.
But, the configuration VTY tells us:
OsmoSTP(config-cs7-listen)# local-ip A.B.C.D IPv4 Address to use for XUA X:X::X:X IPv6 Address to use for XUA
and so the user might think, ah OK I want to use 127.0.0.1 resulting in a config of
cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted route-table system listen m3ua 2905 local-ip 127.0.0.1 accept-asp-connections dynamic-permitted
Actually local-ip 0.0.0.0 will also trigger this issue.
Now let's start osmo-bsc and osmo-msc with the minimal configuration files needed to start up, leaving the rest to default values for the sake of clarify here, although this issue can be observed with a fully configured BSC/MSC:
osmo-bsc.cfg:
msc 0 mgw remote-ip 127.0.0.1
osmo-msc.cfg:
BLANK - Use all defaults.
osmo-bsc will constantly log: Event AS-TRANSFER.req not permitted
although osmo-bsc vty will show:
OsmoBSC# show msc 0 m3ua RI=SSN_PC,PC=0.23.3,SSN=BSSAP RI=SSN_PC,PC=0.23.1,SSN=BSSAP
osmo-msc vty will show:
OsmoMSC# show bsc OsmoMSC#
So one should NOT use an ipv4 address in local-ip, UNLESS ipv6 stack is disabled with:
sysctl net.ipv6.conf.all.disable_ipv6=1
If you have OSMO-STP config with an IPv4 address in local-ip, as soon as you disable the ipv6 stack, you'll see:
[other log messages leading up to...] DMSC NOTICE (msc0) BSSMAP assocation is up
To confirm:
with local-ip ::
there's no problem with ipv4/ipv6 being enabled or not.
Related issues
Updated by pespin almost 3 years ago
So you change the default ipv6 address to an ipv4 address in osmo-stp, and still expect the osmo-msc default ipv6 address to work fine. That's of course wrong.
If you leave the default value in osmo-stp (::), then default remote address value for osmo-msc (::1 I guess) also works.
If you change the default value in osmo-stp, then you also need to adapt clients connecting to it accordingly.
So one should NOT use an ipv4 address in local-ip, UNLESS ipv6 stack is disabled with:
That's not true. One can perfectly configure osmo-stp to use an ipv4 address if you of course also configure nodes connecting to it to also use ipv4.
On the other hand (again as explained above), if you configure osmo-stp to use the default ::, then both v4 and v6 clients can connect just fine.
The "complexity" here may be to understand that by using IPv6 sockets by default when binding, we are actually extending the usability, since SCTP IPv6 sockets allow connections from both IPv4 and IPv6 addresses iirc (when using ::, it binds on both V4 0.0.0.0 and v6).
Updated by laforge over 2 years ago
- Assignee set to pespin
- Priority changed from Low to Normal
Yes, it's obviuous to anyone with sufficient experience of the BSD sockets API on dual-stakc systems.
However, I think this warrants some general documentation in a shared chapter about ss7 related configuration.
Updated by pespin over 2 years ago
- xua_server listens by default on "::", that is, both IPv4 and IPv6 incoming connections are accepted (if IPv6 is disabled on the system, it will listen on "0.0.0.0").
- ASP VTY node osmo_ss7_vty_go_parent(): will fill default values for clients if not set: If IPv6 is enabled in system, local="::" is used, otherwise local="0.0.0.0" is used. remote="127.0.0.1" is always added, and if IPv6 is enabled, "::1" is also added.
- osmo_sccp_simple_client_on_ss7_id(): in general it is called with local="localhost" and remote="localhost". This will resolve as local="::"+remote="::1" if IPv6 is enabled, and otherwise to local="0.0.0.0"+remote="127.0.0.1"
I'm submitting a patch to extend osmo_sccp_simple_client_on_ss7_id() to allow passing NULL default addresses, so that the library internally sets defaults as per the logic in ASP VTY node osmo_ss7_vty_go_parent().
https://gerrit.osmocom.org/c/libosmo-sccp/+/25689 osmo_sccp_simple_client_on_ss7_id(): Allow set internally proper IPv4/v6 ...
However, due to the way the linux SCTP kernel stack is currently implemented (and possibly also due to the fact that SCTP is not really multipath, but extra addresses are handled as backups after handshake negotiations), it will always try to SCTP INIT on the firstly assigned address, and basically ignores the other ones. As a result, there's no sane way to have everything work automatically if someone changes the osmo-stp side to be different than "::" without also changing the client side config.
Updated by pespin over 2 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 90
I improved the related user manual doc here:
https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/25690 cs7-config.adoc: Improve doc on default SS7 SCTP addresses
Updated by pespin over 2 years ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Merged, closing.
