Project

General

Profile

Actions

Bug #5186

closed

local-ip config parameter can cause unclear behaviour on dual IP stack system

Added by keith over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
06/18/2021
Due date:
% Done:

100%

Spec Reference:

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

Related to libosmo-netif - Bug #6279: stream_cli fails to connect when using SCTP if no local address is setResolvedlaforge11/29/2023

Actions
Actions #1

Updated by keith over 2 years ago

  • Description updated (diff)
Actions #2

Updated by pespin over 2 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).

Actions #3

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.

Actions #4

Updated by pespin over 2 years ago

Summary of the issue:
  • 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.

Actions #5

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

Actions #6

Updated by pespin over 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged, closing.

Actions #7

Updated by pespin 3 months ago

  • Related to Bug #6279: stream_cli fails to connect when using SCTP if no local address is set added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)