Bug #2388
closedOsmoPCU sends BVC-RESET over NS-VC which is still in state BLOCKED
0%
Description
- OsmoPCU is performing the NS-RESET procedure successfully
- OsmoPCU is performing the NS-ALIVE procedure successfully
- OsmoPCU is sending the BVC-RESET message before the NS-VC is unblocked using the NS-UNBLOCK procedure
This is too soon. A spec compliant implementation of the SGSN side will thus reject the (first) BVC-RESET due to this too early transmission
Files
Related issues
Updated by laforge almost 7 years ago
actually, it seems it even forwards GMM-PDUs over a blocked BVC.
Updated by laforge over 6 years ago
- Assignee changed from laforge to msuraev
I think it would be best to block all transmission of BSSGP or higher layer messages on the NS level if the NS-VC is not UNBLOCKED.
Updated by msuraev over 6 years ago
- Status changed from New to In Progress
That's odd: bssgp_tx_bvc_reset() is using gprs_ns_sendmsg() which checks that NS is alive and unblocked via gprs_active_nsvc_by_nsei(). Seems like we somehow set the flags too early.
Updated by msuraev over 6 years ago
- Status changed from In Progress to Feedback
- Assignee changed from msuraev to laforge
I'm unable to reproduce this locally with current master of libosmocore, OsmoPCU and OsmoSGSN (I'm using osmo-bts-virtual):
20171129154912764 <0008> gprs_ns.c:266 NSVCI=65534 Creating NS-VC 20171129154912765 <0008> gprs_ns.c:1622 Listening for nsip packets from 10.9.1.105:23000 on 0.0.0.0:23100 20171129154912765 <0008> gprs_ns.c:1641 NS UDP socket at 0.0.0.0:23100 20171129154912765 <0008> gprs_ns.c:266 NSVCI=101 Creating NS-VC 20171129154912765 <0008> gprs_ns.c:1659 NSEI=101 RESET procedure based on API request 20171129154912765 <0008> gprs_ns.c:449 NSEI=101 Tx NS RESET (NSVCI=101, cause=O&M intervention) 20171129154912765 <0008> gprs_ns.c:1523 recv error Connection refused during NSIP recv 20171129154915765 <0008> gprs_ns.c:449 NSEI=101 Tx NS RESET (NSVCI=101, cause=O&M intervention) 20171129154915765 <0008> gprs_ns.c:1523 recv error Connection refused during NSIP recv 20171129154918765 <0008> gprs_ns.c:449 NSEI=101 Tx NS RESET (NSVCI=101, cause=O&M intervention) 20171129154918766 <0008> gprs_ns.c:998 NSVCI=101 Rx NS RESET ACK (NSEI=101, NSVCI=101) 20171129154918766 <0008> gprs_ns.c:558 NSEI=101 Tx NS UNBLOCK (NSVCI=101) 20171129154918766 <0008> gprs_ns.c:1420 NSEI=101 Rx NS UNBLOCK ACK 20171129154918767 <000a> gprs_bssgp_pcu.cpp:541 NS-VC 101 is unblocked. 20171129154918768 <0009> gprs_bssgp_bss.c:292 BSSGP (BVCI=0) Tx BVC-RESET CAUSE=O&M intervention 20171129154918768 <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=-1 (SIGN) BVC_RESET_ACK 20171129154918768 <0009> gprs_bssgp_bss.c:292 BSSGP (BVCI=2) Tx BVC-RESET CAUSE=O&M intervention 20171129154918768 <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=-1 (SIGN) BVC_RESET_ACK 20171129154918768 <0009> gprs_bssgp_bss.c:272 BSSGP (BVCI=2) Tx BVC-BLOCK 20171129154918769 <0009> gprs_bssgp_pcu.cpp:310 Rx BSSGP BVCI=-1 (SIGN) BVC_UNBLOCK_ACK
What kind of configs were used while taking this capture?
Which version were used?
Is there test system available?
Updated by laforge over 6 years ago
- Status changed from Feedback to New
- Assignee changed from laforge to msuraev
this was done on a sysmoBTS while working on interconnection with a Quortus SGSN. Nobody made claims that this can be reproduced with unmodified OsmoSGSN.
You have to re-create the scenario yourself, i.e. make sure that the real or simulated SGSN performs NS-RESET and NS-ALIVE but never NS-UNBLOCKS. If you cannot reproduce then, and/or cannot see based on code review how this might happen, close/reject the ticket.
Updated by msuraev over 6 years ago
Seems like a good candidate for TTCN3 test. Although maybe it would be quicker to alter OsmoSGSN - not sure yet.
Updated by laforge almost 6 years ago
- Assignee set to stsp
- Priority changed from High to Normal
Updated by msuraev over 5 years ago
- Related to Feature #1537: Move the BSSGP handling to libosmocore added
Updated by msuraev over 5 years ago
- Related to Bug #2890: OsmoPCU TTCN-3 test suite not executed by jenkins added
Updated by stsp over 5 years ago
Likely related to: https://gerrit.osmocom.org/c/libosmocore/+/11833
Updated by stsp over 5 years ago
- Status changed from Stalled to Resolved
Should be fixed by above patch which has been merged.