Bug #4926
open
nano3G disconnect / reconnect cycle with SCTP multi-homing
Added by laforge over 3 years ago.
Updated over 3 years ago.
Description
I just spent a couple of hours trying to set up a nano3G against an osmo-hnbgw in the following situation:
- Debian 10 (buster) on amd64
- multiple network interfaces
- default osmo-hnbgw configuration
The nano3G connects the Iuh interface, sends the HNB_REGISTER_REQ, the hnbgw answers with HNB_REGISTER_ACK and a few seconds later it disconnects Iuh and res-starts the connection about 2 minutes later. This loop continuses indefinitely.
dmi states:
amsConnectionCloseCause (2822) = CONNECTION_CLOSE_CAUSE_INVALID_CONFIGURATION (0)
there are no relevant log messages to be found on the nano3G.
- % Done changed from 0 to 20
This is related to #4925
By default the SCTP INIT_ACK chunk from osmo-hnbgw to the nano3G contains all of the local IP addresses on all interfaces - even those that the nano3G can never reach.
Once I lock the osmo-hnbgw to a single local IP address (the one on the interface facing to the nano3G), it works as expected.
hnbgw
iuh
local-ip 192.168.11.4
Given that the nano3G is one of the most frequenfly used devices with osmo-hnbgw, I would think it probably makes sense to somehow constrain the local IP addresses of the hnbgw by default. I would guess most people fall into this trap.
It's may be the multi-addr related patches introduced in January 2020 whihc first introduced this behavior?
- Related to Bug #4925: SCTP multihoming / ABORT between osmo-msc and osmo-stp added
Are loopback addresses also being announced? If they are, that's a linux kernel bug IMHO, and that may be the one triggering issues on nano3g side. I recall seeing similar issues with different types of addresses being used together as source and destination (those types are specified in SCTP RFC and there's even some sysctl to control behavior from linux side).
Also available in: Atom
PDF
