Project

General

Profile

Bug #4599

counter group sgsn:pdpctx already exists for index X, instead using Y

Added by laforge 26 days ago. Updated 21 days ago.

Status:
New
Priority:
Normal
Assignee:
sysmocom
Category:
-
Target version:
-
Start date:
06/08/2020
Due date:
% Done:

0%

Spec Reference:

Description

When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:

<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.

I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.

The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.

lynxis any ideas?


Related issues

Related to OsmoSGSN - Bug #4604: Lots of "Unusual event"New06/08/2020

History

#1 Updated by laforge 26 days ago

  • Related to Bug #4604: Lots of "Unusual event" added

#2 Updated by lynxis 23 days ago

  • Assignee changed from lynxis to laforge

This is a problem of the SGSN code and how it allocates rate counter groups.

The problem here is, that the sgsn tries to allocate a new rate counter for "sgsn:pdpctx" and use as identifier the nsapi. But the nsapi is only unique within a single MS. The rate counter expects this identifier to be unique across the SGSN.

#3 Updated by laforge 21 days ago

  • Status changed from Feedback to New
  • Assignee changed from laforge to sysmocom

Ok, so the rate counter group allocations should not simply use the NSAPI but some kind of number that is globally unique.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)