Project

General

Profile

Bug #4926

nano3G disconnect / reconnect cycle with SCTP multi-homing

Added by laforge 30 days ago. Updated 23 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12/28/2020
Due date:
% Done:

20%

Spec Reference:

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.


Related issues

Related to libosmo-sccp + libosmo-sigtran - Bug #4925: SCTP multihoming / ABORT between osmo-msc and osmo-stpNew12/28/2020

History

#1 Updated by laforge 30 days 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?

#2 Updated by laforge 30 days ago

  • Related to Bug #4925: SCTP multihoming / ABORT between osmo-msc and osmo-stp added

#3 Updated by pespin 23 days 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).

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)