Project

General

Profile

Actions

Bug #4870

closed

BTS features parsed too late

Added by lynxis about 1 year ago. Updated 12 months ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
11/27/2020
Due date:
% Done:

100%

Spec Reference:

Description

The BSC requests the BTS features after it has used to decide if the BTS can be used for IPv6.


Files

oml_too_late.pcapng oml_too_late.pcapng 374 KB lynxis, 11/28/2020 01:19 AM
Actions #1

Updated by lynxis about 1 year ago

  • Subject changed from BTS features are requested too late to BTS features requested too late
Actions #2

Updated by lynxis about 1 year ago

The BSC parse the BTS features which are requested via "Get Attribute" too late to allow the NSVC MO to check for the IPv6 feature.
The BSC already generated the NSVC MO Set Attribute packet when it receives the "State Event Report" for the NSVC MO which is before the feature response is parsed.

So in general I would expect to parse the feature message before triggering any MO object response.

Actions #3

Updated by lynxis about 1 year ago

Actions #4

Updated by lynxis about 1 year ago

When the BTS is connected a second time, the features from the first time are still present. So reconnecting a BTS could be considered as dirty workaround :).

Actions #5

Updated by laforge about 1 year ago

  • Priority changed from Normal to High
Actions #6

Updated by pespin about 1 year ago

The problem is most probably that I didn't work on the FSMs for the gprs-related MO, such as NSVC, so those are still handled the old way by pushing everything quite quickly.

So in order to solve this iiuc we need to:
  • Implement FSM for misisng gprs-related MOs,
  • In the BSC, Delay set up of NSVC MO until we received BTS Get Attributes Response.
Actions #7

Updated by lynxis about 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 70

Since my workaround doesn't work (thanks race conditions!). I've created a NSVC fsm and a simple feature negotiating flag.

pespin can you review it and test it against a nanobts?

https://gerrit.osmocom.org/c/osmo-bsc/+/21451
https://gerrit.osmocom.org/c/osmo-bsc/+/21452

Actions #8

Updated by pespin about 1 year ago

  • % Done changed from 70 to 90

I reworked lynxis patches on top of mine adding FSMs for all GPRS-related MOs.

Issue should be fixed by these:
remote: https://gerrit.osmocom.org/c/osmo-bsc/+/21452 Introduce NM GPRS NSVC FSM
remote: https://gerrit.osmocom.org/c/osmo-bsc/+/21501 abis_nm: Simplify param passing to abis_nm_rx_get_attr_resp()
remote: https://gerrit.osmocom.org/c/osmo-bsc/+/21502 Handle BTS/BBTRANSC Get Attributes (Ack) in NM FSMs
remote: https://gerrit.osmocom.org/c/osmo-bsc/+/21538 Fix typo in function nanobts_attr_nsvc_get [NEW]
remote: https://gerrit.osmocom.org/c/osmo-bsc/+/21451 oml: Delay configuring NSVC until BTS features are negotiated

Actions #9

Updated by pespin about 1 year ago

  • Assignee changed from pespin to lynxis

All patches ahve been merged except the last one. Reassigning to lynxis so he tests everything's fine with that one since he can reproduce the issue.

Once merged and issue is for sure fixed, feel free to close the ticket.

Actions #10

Updated by pespin 12 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

AFAIC lynxis already tested this and it's working fine, so closing the ticket.

Actions #11

Updated by lynxis 12 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)