Project

General

Profile

Actions

Bug #4956

closed

gbproxy tries to BVC-RESET SGSN-side PTP-BVC before SIG-BVC

Added by laforge over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
01/18/2021
Due date:
% Done:

100%

Spec Reference:

Description

If the SIG-BVC on the SGSN side for some reason is not completing the BVC-RESET procedure, we end up sending BVC-RESET for the PTP-BVC, triggered by the PTP BVC-RESET on the PCU side.

I'm not sure if
  • the PCU-side BVC-RESET shouldn't even complete if we don't manage to BVC-RESET the SGSN side, or
  • we should simply delay transmitting the PTP BVC-RESET until the SIG BVC-RESET happened on the SGSN side.

The latter seems more well-defined particularly in the situation with multiple SGSNs around.

Actions #1

Updated by laforge over 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80

Well, it actually tries to RESET the signaling BVC first, but due to a bug in libosmogb/ns2, this is never sent out (reporting RECOVERY of the NSE too soon).

So I think it's not osmo-gbproxy to blame here, but ns2.

See https://gerrit.osmocom.org/c/libosmocore/+/22282

Actions #2

Updated by laforge over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

patch merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)