Bug #4926
opennano3G disconnect / reconnect cycle with SCTP multi-homing
20%
Description
- 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.
Related issues
Updated by laforge about 3 years ago
- % 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?
Updated by laforge about 3 years ago
- Related to Bug #4925: SCTP multihoming / ABORT between osmo-msc and osmo-stp added
Updated by pespin about 3 years ago
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).