Project

General

Profile

Bug #5186

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

Added by keith 4 months ago. Updated 6 days 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.

Associated revisions

Revision b92c3ae2 (diff)
Added by pespin 16 days ago

cs7-config.adoc: Improve doc on default SS7 SCTP addresses

Related: OS#5186
Change-Id: Ic8d9c00ae50907f1adad8f70b773e7b1362c4f50

Revision f594b7df (diff)
Added by pespin 14 days ago

osmo_sccp_simple_client_on_ss7_id(): Allow set internally proper IPv4/v6 default hosts

Allow user apps to relay the decision of proper default local/remote
hosts values to the library. Proper configuration of these addresses can
be quite cumbersome to get correctly, or confusing at least. That's due
to the multi-homing feature of SCTP where both IPv4 and IPv6 are
involved.

We were already doing this kind of automatic setup in
osmo_ss7_vty_go_parent(), where we do validations and assign addresses
based on IPv6 availability.
On the other hand, apps using osmo_sccp_simple_client_on_ss7_id() API
usually pass "localhost" as default address. In Linux, when IPv6 is enabled
localhost is resolved as "::1", and "127.0.0.1" when IPv6 is disabled.

Let's instead allow apps to relay the setup to the lib, so same addresses
can be applied both during VTY command as well as if there was no VTY
setup at all.

Related: OS#5186
Change-Id: I82e203612571b7651d758d8148661f706a1642ba

History

#1 Updated by keith 4 months ago

  • Description updated (diff)

#2 Updated by pespin 4 months 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).

#3 Updated by laforge about 1 month 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.

#4 Updated by pespin 16 days 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.

#5 Updated by pespin 16 days 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

#6 Updated by pespin 6 days ago

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

Merged, closing.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)