Project

General

Profile

Bug #4870

BTS features parsed too late

Added by lynxis about 2 months ago. Updated about 1 month 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.

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

History

#1 Updated by lynxis about 2 months ago

  • Subject changed from BTS features are requested too late to BTS features requested too late

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

#3 Updated by lynxis about 2 months ago

#4 Updated by lynxis about 2 months 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 :).

#5 Updated by laforge about 2 months ago

  • Priority changed from Normal to High

#6 Updated by pespin about 2 months 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.

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

#8 Updated by pespin about 1 month 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

#9 Updated by pespin about 1 month 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.

#10 Updated by pespin about 1 month 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.

#11 Updated by lynxis about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)