Project

General

Profile

Bug #5230

hnbgw fails to connect to the sgsn

Added by lynxis 11 days ago. Updated 4 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/07/2021
Due date:
% Done:

0%

Spec Reference:

Description

On the event gsm setup I've noticed that sometimes the packets doesn't flow between the daemons even all are up.
I would guess it's a stale connection or a wrong routing.

It's a full setup with osmo-bsc/msc/sgsn/hnbgw (+ the other non stp services).
I restart a daemon and the data doesn't flow even the daemon is reconnecting.

My current failure is with a nano3g <> hnbgw <> stp <> sgsn.
While the CS path to the msc works.

The UE is sending a GPRS-ATTACH-REQ which correlates to the following osmo-hnbgw failure message:

Sep 07 17:48:57 rc3-gsm osmo-hnbgw[9345]: 20210907174857511 DLSCCP ERROR Received unknown conn-id 1002 for primitive N-DATA.request (sccp_scoc.c:1758)
[...] for every Attach Request 1

I've noticed this bug from time to time while working with the event setup. I could image a bug in the sccp or stp.

bug_2021_09_07.tar.gz bug_2021_09_07.tar.gz 5.26 KB hnbgw,sgsn,stp logs lynxis, 09/07/2021 04:07 PM

History

#1 Updated by laforge 10 days ago

On Tue, Sep 07, 2021 at 04:08:36PM +0000, lynxis [REDMINE] wrote:

> Sep 07 17:48:57 rc3-gsm osmo-hnbgw[9345]: 20210907174857511 DLSCCP ERROR Received unknown conn-id 1002 for primitive N-DATA.request (sccp_scoc.c:1758)
> [...] for every Attach Request 1
> 

I've noticed this bug from time to time while working with the event setup. I could image a bug in the sccp or stp.

I would think it either means the hnbgw has been re-started, or somehow the SCCP connections have timed out on the hnbgw but not on the SGSN. That's the only reasonable explanation why we get a inbound SCCP message for a non/no-longer existing conn.

Might also be related to the SCCP IT (interval timer) message which acts as keepalive.

#2 Updated by laforge 4 days ago

  • Status changed from New to Feedback
  • Assignee set to lynxis

FYI: osmo-stp is not involved in interpreting/modifying/generating those SCCP messages. SCCP is just passed through on top of M3UA. So you can exclude that from being the cause, it is something between the two SCCP users, i.e. hnbgw and sgsn. A reasonably long pcap file [to catch any earlier connections that timed out meanwhile] would be useful, if it doesn't have the obious cause I stated before: one of the two sides [in your example, osmo-hnbgw] has been re-started after SCCP connections were already established between hnbgw and sgsn.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)