Project

General

Profile

Bug #2388

OsmoPCU sends BVC-RESET over NS-VC which is still in state BLOCKED

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

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
07/23/2017
Due date:
% Done:

0%

Spec Reference:

Description

When looking at the sequence of events:
  • 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


Related issues

Related to OsmoPCU - Feature #1537: Move the BSSGP handling to libosmocoreNew02/22/2016

Related to OsmoPCU - Bug #2890: OsmoPCU TTCN-3 test suite not executed by jenkinsResolved01/27/2018

Associated revisions

Revision 797558ea (diff)
Added by Stefan Sperling over 2 years ago

send NS_POUT_UNBLOCK_ACK before signalling S_NS_UNBLOCK

In gprs_ns_process_msg(), we were dispatching the S_NS_UNBLOCK
signal before sending out the NS_POUT_UNBLOCK_ACK message.

Signal handlers might send messages to the other side, assuming
that NS is now unblocked. However, since such messages will arrive
before the UNBLOCK_ACK message the receiver might discard them.
This problem has been observed with our TTCN3 BSSGP_Emulation
as a peer to osmo-pcu.

This patch makes TTCN3 PCU TC_paging() test pass regardless of
whether the test or osmo-pcu is started first. Before this patch,
this test would only pass if the test was started before osmo-pcu.
A remaining problem is that the test does not yet keep passing
reliably unless osmo-pcu is restarted between test runs.

Change-Id: I3af54a14bb6bcfa167c9a9d9f67835e7f5b9f1bb
Related: OS#2890
Related: OS#2388

Revision c6bfc63d (diff)
Added by Stefan Sperling over 2 years ago

document unblock-ack vs. signalling in gprs_ns_process_msg()

Since commit 797558ea1768e464f9559c5f7a4f3f4285c5de25 we send the
NS_UNBLOCK_ACK message before dispatching the NS_UNBLOCK signal,
instead of afterwards.

Add comments which explain the intended order of events.

Suggested-by: Pau
Related: OS#2388

Change-Id: I4b93853c952a97302f8afc14f462f22c3e487564

Revision e76afc4f (diff)
Added by Stefan Sperling over 2 years ago

update gbproxy test expected output

libosmocore commit 797558ea1768e464f9559c5f7a4f3f4285c5de25
changed the order of NS_UNBLOCK_ACK transmission dispatching
of the NS_UNBLOCK signal. Update expected output of gbproxy
tests accordingly to make these tests pass again.

Change-Id: Ia3df811755b1c88cf7a27a466677b24a6c32fd8e
Related: OS#2388

History

#1 Updated by laforge over 3 years ago

actually, it seems it even forwards GMM-PDUs over a blocked BVC.

#2 Updated by laforge over 3 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.

#3 Updated by laforge over 3 years ago

  • Priority changed from Normal to High

#4 Updated by msuraev over 3 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.

#5 Updated by msuraev over 3 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?

#6 Updated by laforge over 3 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.

#7 Updated by msuraev over 3 years ago

Seems like a good candidate for TTCN3 test. Although maybe it would be quicker to alter OsmoSGSN - not sure yet.

#8 Updated by msuraev over 3 years ago

  • Status changed from New to In Progress

#9 Updated by msuraev over 3 years ago

  • Status changed from In Progress to Stalled

#10 Updated by laforge about 3 years ago

  • Assignee deleted (msuraev)

#11 Updated by laforge almost 3 years ago

  • Assignee set to stsp
  • Priority changed from High to Normal

#12 Updated by msuraev over 2 years ago

  • Related to Feature #1537: Move the BSSGP handling to libosmocore added

#13 Updated by msuraev over 2 years ago

  • Related to Bug #2890: OsmoPCU TTCN-3 test suite not executed by jenkins added

#15 Updated by stsp over 2 years ago

  • Status changed from Stalled to Resolved

Should be fixed by above patch which has been merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)