Project

General

Profile

Actions

Bug #3651

closed

SS request results in lingering lchan

Added by keith over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
10/12/2018
Due date:
% Done:

100%

Spec Reference:

Description

SS codes such as *#21# are not handled correctly

Output on the HLR:

Fri Oct 12 14:55:26 2018 DSS <0004> hlr_ussd.c:467 262420312915730/0x20000003: Process SS (BEGIN)
Fri Oct 12 14:55:26 2018 DSS <0004> hlr_ussd.c:401 262420312915730/0x20000003: SS CompType=Invoke, OpCode=IngerrogateSS

followed by:

Fri Oct 12 14:55:56 2018 DSS <0004> hlr_ussd.c:195 262420312915730/0x20000003: SS Session Timeout, destroying

But osmo-bsc still has:

OsmoBSC# show lchan s        
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 5 dBm RXL-FULL-dl:  -47 dBm RXL-FULL-ul:  -56 dBm
OsmoBSC#

and this persists, with some phones, forever.


Files

local.pcap local.pcap 10.1 KB A / GSUP keith, 10/12/2018 02:18 PM
SS-abis.pcap SS-abis.pcap 34.8 KB Abis for *#21# keith, 10/12/2018 02:18 PM
USSD-good-abis.pcap USSD-good-abis.pcap 4.14 KB Abis for *#100# keith, 10/12/2018 02:18 PM
abis.pcap abis.pcap 124 KB keith, 10/13/2018 10:11 AM
local.pcap local.pcap 109 KB Capture of A/GSUP for above description. keith, 10/13/2018 10:20 AM
abis.pcap abis.pcap 28.2 KB Nokia calling KRZR keith, 10/13/2018 10:43 AM
local.pcap local.pcap 178 KB A / GSUP for the latest test keith, 10/13/2018 10:51 AM

Related issues

Related to OsmoMSC - Feature #3655: Introduce self-destruction timer for SS/USSD connectionsResolvedfixeria10/16/2018

Actions
Actions #2

Updated by fixeria over 5 years ago

  • Project changed from Cellular Network Infrastructure to OsmoHLR
  • Status changed from New to Feedback
  • Assignee set to fixeria
  • Priority changed from Normal to High
  • % Done changed from 0 to 90

Hi Keith,

thanks for this report!

I've managed to reproduce the problem in my virtual network,
and implemented a fix for that, please see:

https://gerrit.osmocom.org/11341/

In short, the problem is that 'structured' SS requests are not answered at all.
We should reject such requests by sending returnError message until we start to support them.

Actions #3

Updated by keith over 5 years ago

Nice! Thanks for fixing that!

I wonder if there should be some kind of "failsafe" timer also on the MSC (or maybe it's BSC side) that would shutdown the channel in the case that the HLR became unresponsive.

I should have also included a trace of the call that I mentioned in the email.. Let me try to get that now before I pull your HLR patch....

Actions #4

Updated by keith over 5 years ago

OK, Maybe I'll make a new ticket for this, but as it is possibly not easy to reproduce without the bug mentioned here, I'll put it here for now..

This is what I do and what I observe, using a Nokia 6070.

Dial *#21# + SEND

Phone says Requesting.. and I observe SDCCH activity on the spectrum Uplink.
I press END on the phone.
Phone says Request not Confirmed, appears to go to standby and SDCCH Uplink actvity continues.
I call a number on phone and press SEND
Phone immediately says "Error in connection" and I observe TCH activity on spectrum.
Phone appears to returns to standby and TCH continues.

BSC at this point shows:

OsmoBSC# show lchan s
BTS 0, TRX 0, Timeslot 1 TCH/F, Lchan 0, Type TCH_F, State ESTABLISHED - L1 MS Power: 5 dBm RXL-FULL-dl:  -47 dBm RXL-FULL-ul:  -50 dBm

Some several minutes later, phone TX is still active, TCH is still active.
I issue drop bts from BSC
Phone display shows Request not completed

(in the pcap, I didn't wait so long before dropping the bts)

Actions #5

Updated by keith over 5 years ago

Actions #6

Updated by keith over 5 years ago

Adding Capture of A/GSUP for above description.

Actions #7

Updated by keith over 5 years ago

Further,

With the HLR patch in place, the KRZR now camps, issues the SS and goes idle. All Good. :)
Subsequently calling the KRZR from the Nokia (with the error provoked in freeswitch by #3650) results in a lingering SDCCH on the KRZR!

(with osmo-sip-connector patched to override the payload_type, call sets up, connects, and completes with success)

Still, It strikes me we are missing something. abis pcap of the above attached.

Actions #8

Updated by keith over 5 years ago

A / GSUP pcap for above. (there's some OsmoVTY, SIP and freeswitch console noise in there too)

Note, these A /GSUP captures were not captured at the same time as the abis, but it was the same sequence of events.

Actions #9

Updated by fixeria over 5 years ago

  • Related to Feature #3655: Introduce self-destruction timer for SS/USSD connections added
Actions #10

Updated by fixeria over 5 years ago

Hi Keith,

I wonder if there should be some kind of "failsafe" timer
also on the MSC (or maybe it's BSC side) that would shutdown
the channel in the case that the HLR became unresponsive.

Yep, definitely. I created an issue, please see: #3655.

With the HLR patch in place, the KRZR now camps,
issues the SS and goes idle. All Good. :)

Should we mark this issue as "resolved" then?

Subsequently calling the KRZR from the Nokia
results in a lingering SDCCH on the KRZR!

If it's still related to the SS/USSD, I am feeling a bit lost :)

Actions #11

Updated by fixeria over 5 years ago

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

The following test case confirms that the problem was actually solved:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11960/

so, closing.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)