Bug #4599

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

Added by laforge 11 months ago. Updated 8 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


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


#1 Updated by laforge 11 months ago

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

#2 Updated by lynxis 11 months 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 11 months 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.

#4 Updated by MPoslusny 8 months ago

I confirm that I see this message on our installation often as well.
Could this have an effect on the MS connection time?

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)