Project

General

Profile

Actions

Bug #4926

open

nano3G disconnect / reconnect cycle with SCTP multi-homing

Added by laforge about 3 years ago. Updated about 3 years 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

Actions
Actions #1

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?

Actions #2

Updated by laforge about 3 years ago

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

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).

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)