Bug #4870
closedBTS features parsed too late
Added by lynxis over 3 years ago. Updated over 3 years ago.
100%
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 |
Updated by lynxis over 3 years ago
- Subject changed from BTS features are requested too late to BTS features requested too late
Updated by lynxis over 3 years ago
- File oml_too_late.pcapng oml_too_late.pcapng added
- Subject changed from BTS features requested too late to BTS features parsed too late
- Assignee changed from lynxis to pespin
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.
Updated by lynxis over 3 years 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 :).
Updated by pespin over 3 years 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.
Updated by lynxis over 3 years 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
Updated by pespin over 3 years 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
Updated by pespin over 3 years 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.
Updated by pespin over 3 years 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.