Project

General

Profile

Actions
Copy link

Bug #1830

closed

Sending SMS via VTY after 'silent-call' command provoked multiple copies of the same text message to be send

Added by wirelesss over 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
dexter
Category:
-
Target version:
OpenBSC version: 0.15.0.498-582e4
Start date:
10/19/2016
Due date:
% Done:

100%

Spec Reference:

Description

During test of a 'silent-call' command followed by sending of SMS via VTY, provoked multiple copies of the same text message to be send to the MS.

Package: libosmocore
Version: 0.9.3.20160930
APT-Sources: http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_8.0 ./ Packages
Description: Open Source MObile COMmunications CORE library

Related commands are given below:

OpenBSC> subscriber imsi 1640000000071 silent-call start sdcch                                                
OpenBSC> % silent call on ARFCN 870 timeslot 0
OpenBSC> subscriber imsi 1640000000071 sms sender imsi 901700000007802 send .testing_sms_during _silent _call1  <--- after this command multiple copies of SMS ".testing_sms_during _silent _call1" is received. 
OpenBSC> subscriber imsi 1640000000071 sms sender imsi 901700000007802 send .testing_sms_during _silent _call2
OpenBSC> subscriber imsi 1640000000071 sms sender imsi 901700000007802 send .testing_sms_during _silent _call3
OpenBSC> subscriber imsi 1640000000071 sms sender imsi 901700000007802 send .testing_sms_during _silent _call4
OpenBSC> subscriber imsi 1640000000071 sms sender imsi 901700000007802 send .testing_sms_during _silent _call5
OpenBSC> subscriber imsi 1640000000071 ussd-notify 1 .probe                                                   
OpenBSC> subscriber imsi 1640000000071 sms sender imsi 901700000007802 send .testing_sms_during _silent _call5
OpenBSC> subscriber imsi 1640000000071 silent-call stop                                                         <--- command 'silent-call stop' stopped receipt of the SMSs.

pcap file is attached.

This behavior is detected using Black Berry Curve 8520 and Sony Ericsson G705u.

Files

capture_BlackBerry_ISDN_1640000000071.pcap capture_BlackBerry_ISDN_1640000000071.pcap 131 KB wirelesss, 10/19/2016 04:37 PM
sms with silent call_tarce 9 Nov sms with silent call_tarce 9 Nov 72.5 KB Log file wirelesss, 11/09/2016 03:00 PM
sms_resend_during_silent_call.tar sms_resend_during_silent_call.tar 270 KB dexter, 01/20/2017 10:03 AM
Actions
Copy link
 #1

Updated by laforge over 7 years ago

please preferrably also include the version of the openbsc package (or whatever debian package includes the OsmoNITB binary exposing this behaviour). You can always use 'show version' on the vty.

Actions
Copy link
 #2

Updated by wirelesss over 7 years ago

OpenBSC version: 0.15.0.498-582e4

Actions
Copy link
 #3

Updated by wirelesss over 7 years ago

  • Target version set to OpenBSC version: 0.15.0.498-582e4
Actions
Copy link
 #4

Updated by wirelesss over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30
Actions
Copy link
 #5

Updated by laforge over 7 years ago

it would be great to not only have the pcap file, but also have detailed log output, particularly of the SMS logging subsystem.

Actions
Copy link
 #7

Updated by laforge over 7 years ago

  • Status changed from In Progress to New
  • Assignee set to dexter
Actions
Copy link
 #8

Updated by dexter about 7 years ago

By looking at the libpcap traces the osmo-nitb writes I was able to spot that the CP-ACK message is missing when a silent call runs. On the first look this gives the impression that the phone woule be unable to send the CP-ACK for some reason. However, the logtext shows something different:

Thu Jan 19 14:51:24 2017 <0000> abis_rsl.c:2009 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION
Thu Jan 19 14:51:24 2017 <0000> gsm_04_08.c:3723 Dispatching 04.08 message, pdisc=9
Thu Jan 19 14:51:24 2017 <0022> silent_call.c:79 Discarding L3 message from a silent call.
Thu Jan 19 14:51:25 2017 <0000> abis_rsl.c:2009 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION
Thu Jan 19 14:51:25 2017 <0000> gsm_04_08.c:3723 Dispatching 04.08 message, pdisc=9
Thu Jan 19 14:51:25 2017 <0022> silent_call.c:79 Discarding L3 message from a silent call.
Thu Jan 19 14:51:35 2017 <0000> abis_rsl.c:2009 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION
Thu Jan 19 14:51:35 2017 <0000> gsm_04_08.c:3723 Dispatching 04.08 message, pdisc=9
Thu Jan 19 14:51:35 2017 <0022> silent_call.c:79 Discarding L3 message from a silent call.
Thu Jan 19 14:51:35 2017 <0000> abis_rsl.c:2009 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION
Thu Jan 19 14:51:35 2017 <0000> gsm_04_08.c:3723 Dispatching 04.08 message, pdisc=9
Thu Jan 19 14:51:35 2017 <0022> silent_call.c:79 Discarding L3 message from a silent call.
Thu Jan 19 14:51:44 2017 <0000> abis_rsl.c:2009 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION
Thu Jan 19 14:51:44 2017 <0000> gsm_04_08.c:3723 Dispatching 04.08 message, pdisc=9
Thu Jan 19 14:51:44 2017 <0022> silent_call.c:79 Discarding L3 message from a silent call.
Thu Jan 19 14:51:45 2017 <0000> abis_rsl.c:2009 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION
Thu Jan 19 14:51:45 2017 <0000> gsm_04_08.c:3723 Dispatching 04.08 message, pdisc=9

Looking for "Discarding L3 message from a silent call" in silent_call.c we find the following:

/* receive a layer 3 message from a silent call */
int silent_call_rx(struct gsm_subscriber_connection *conn, struct msgb *msg)
{
    /* FIXME: do something like sending it through a UDP port */
    LOGP(DLSMS, LOGL_NOTICE, "Discarding L3 message from a silent call.\n");
    return 0;
}

I still wonder why I do not see the CP-ACK message in the pcap file. Probably osmo-nitb only records messages that are actually processed. Looking at the original trace from Ivalo one can see that the CP-ACK messages are transmitted alog with CP-ERROR messages. My guess is that the CP-ERROR is the result of a slighty confused SMS-Protocol state.

The issue probably can be fixed by fixing the implementation of silent_call_rx() in a way that it forwards the incoming CP-ACK to the SMS protocol stack of osmo-nitb.

Actions
Copy link
 #9

Updated by laforge about 7 years ago

Ok, I think there is some general misunderstanding on various sides
here.

  • the silent-call feature was originally implemented to
    • play with the silent call in general
    • open a RR connection / dedicated channel to do fuzzing of handets

So it was not intended to be used for regular communication like SMS/CC
etc. This might not have been obvious to people trying this, and I even
have forgotten about it.

Since the 'external fuzzer interface' (see my FIXME about a UDP socket)
has not been completed/implemented in all those years, I think it is
best to ignore it for now and to indeed connect the regular MM/CC/SMS
layer3 protocol handling to dedicated channels in silent mode.

If somebody ever wants to introduce the external fuzzer socket
interface, he will have to have some kind of per-lchan state whetehr or
not the higher-level protocols shall be used or not. Might be worth
mentioning this in the commit log of whatever patch will result from
fixing this current issue.

Actions
Copy link
 #10

Updated by dexter about 7 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 30 to 100

Removed the fuzzer code by placing ifdefs around it, since I am not sure if it is good to remove it entirely (maybe we should?). SMS now works as expected.

See also: https://gerrit.osmocom.org/#/c/1930/

Actions
Copy link
 #11

Updated by dexter about 7 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #12

Updated by laforge about 7 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)