Project

General

Profile

Actions

Bug #6075

closed

ussd code scrambled

Added by neels 8 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
06/28/2023
Due date:
% Done:

70%

Spec Reference:

Description

I am currently testing 3G hardware and see this problem with USSD:

  • when I send '*0#', the osmo-hlr log says the code is '*'.
  • when I send '*#100#', the log says 'ªQ [...] '

this happens with current master.
details follow.


Files

ussd.pcapng ussd.pcapng 1.42 KB neels, 06/28/2023 04:49 AM
Actions #1

Updated by neels 8 months ago

attached file goes with this log:

20230628044243197 DLGSUP DEBUG GSUP 8: MSC-00-00-00-00-00-00: IMSI-901700000046740 OSMO_GSUP_MSGT_PROC_SS_REQUEST: new request: {USSD OSMO_GSUP_MSGT_PROC_SS_REQUEST: imsi="901700000046740" session_id=536870914 session_state=BEGIN} (gsup_req.c:138)
20230628044243197 DSS DEBUG 901700000046740/0x20000002: Process SS (BEGIN) (hlr_ussd.c:545)
20230628044243197 DSS DEBUG Could not find Route for USSD Code 'ªQ                         
                                                                  ' (hlr_ussd.c:138)
20230628044243197 DSS INFO 901700000046740/0x20000002: USSD CompType=Invoke, OpCode=ProcessUssReq 'ªQ
                                                                                                     ' (hlr_ussd.c:487)
20230628044243197 DSS NOTICE 901700000046740/0x20000002: USSD for unknown code 'ªQ                                     
                                                                                  ' (hlr_ussd.c:492)
20230628044243197 DSS NOTICE 901700000046740/0x20000002: Tx ReturnError(0, 0x12) (hlr_ussd.c:323)   
20230628044243197 DLGSUP DEBUG GSUP 8: MSC-00-00-00-00-00-00: IMSI-901700000046740 OSMO_GSUP_MSGT_PROC_SS_REQUEST: Tx response: {USSD OSMO_GSUP_MSGT_PROC_SS_RESULT: imsi="901700000046740" session_id=536870914 session_state=END} (hlr_ussd.c:247)

So in the pcap, the USSD string is perfectly fine, but osmo-hlr fails to route it to the entry in the config:

hlr
 ussd route prefix *#100# internal own-msisdn
Actions #2

Updated by fixeria 8 months ago

The DataCodingScheme IE in your PCAP looks unusual, note the Language:

        GSM Mobile Application
            Component: invoke (1)
                invoke
                    invokeID: 0
                    opCode: localValue (0)
                        localValue: processUnstructuredSS-Request (59)
                    ussd-DataCodingScheme: 00
                        0000 .... = Coding Group: Coding Group 0(Language using the GSM 7 bit default alphabet) (0)
                        .... 0000 = Language: German (0)  <----- (!)
                    ussd-String: aa510c061b01
                        USSD String: *#100#

Usually it's set to 1111 meaning Language unspecified. Perhaps gsm0480_parse_facility_ie() is unable to handle German?

Actions #3

Updated by fixeria 8 months ago

fixeria wrote in #note-2:

The DataCodingScheme IE in your PCAP looks unusual, note the Language: [...]
Usually it's set to 1111 meaning Language unspecified. Perhaps gsm0480_parse_facility_ie() is unable to handle German?

I checked gsm0480_parse_facility_ie() in libosmocore.git and found this in parse_process_uss_req():

/**
 * According to GSM 04.08, 4.4.2 "ASN.1 data types":
 * the USSD-DataCodingScheme shall indicate use of
 * the default alphabet using the 0x0F value.
 */
if (dcs == 0x0F) {
        /* Calculate the amount of 7-bit characters */
        num_chars = (num_chars * 8) / 7;

        gsm_7bit_decode_n_ussd((char *)req->ussd_text,
                sizeof(req->ussd_text), &(uss_req_data[7]), num_chars);

        return 1;
} else {
        memcpy(req->ussd_text, &(uss_req_data[7]), num_chars);
        return 1;
}

So we call gsm_7bit_decode_n_ussd() if DCS == 0x0f, otherwise we just copy the encoded buffer as if it was just an ASCII string.
But apparently this is not really an ASCII string, but a 7-bit encoded string as the 4 MSB bits indicate.

Actions #4

Updated by fixeria 8 months ago

  • Status changed from New to Feedback
  • Assignee set to neels

neels please give this WIP patch a try:

https://gerrit.osmocom.org/c/osmo-hlr/+/33528 USSD: fix handling of ussd-DataCodingScheme != 0x0f

and btw, what UE is exhibiting this behavior? I am wondering if the DCS/language it indicates depends on the UI language you selected.

Actions #5

Updated by neels 8 months ago

neels please give this WIP patch a try:

https://gerrit.osmocom.org/c/osmo-hlr/+/33528 USSD: fix handling of ussd-DataCodingScheme != 0x0f

it works!

Jun 29 18:55:02 arn-testnitb osmo-hlr[247433]: 20230629185502689 DSS DEBUG 901700000046968/0x20000007: Process SS (BEGIN) (hlr_ussd.c:576)
Jun 29 18:55:02 arn-testnitb osmo-hlr[247433]: 20230629185502689 DSS NOTICE USSD DataCodingScheme (0x00): the Language is usually set to 15 (unspecified), but the request indicates 0 - ignoring this (hlr_ussd.c:142)
Jun 29 18:55:02 arn-testnitb osmo-hlr[247433]: 20230629185502689 DSS DEBUG Found IUSE 'own-msisdn' (prefix '*#100#') for USSD Code '*#100#' (hlr_ussd.c:161)

and btw, what UE is exhibiting this behavior? I am wondering if the DCS/language it indicates depends on the UI language you selected.

This is from Simcom and Sierra modems set up in a testbed at sysmocom, connected to a 3G hNodeB.

I found out that there is an optional 'dcs' parameter of AT+CUSD command that sends a USSD req.
When I set that to 15, osmo-hlr does not complain anymore:

AT+CUSD=1,"*#100#",15

Jun 29 19:01:43 arn-testnitb osmo-hlr[247433]: 20230629190143032 DSS DEBUG 901700000046968/0x20000008: Process SS (BEGIN) (hlr_ussd.c:576)
Jun 29 19:01:43 arn-testnitb osmo-hlr[247433]: 20230629190143032 DSS DEBUG Found IUSE 'own-msisdn' (prefix '*0#') for USSD Code '*0#' (hlr_ussd.c:161)
Jun 29 19:01:43 arn-testnitb osmo-hlr[247433]: 20230629190143032 DSS INFO 901700000046968/0x20000008: USSD CompType=Invoke, OpCode=ProcessUssReq '*0#' (hlr_ussd.c:518)

So the patch can be helpful, but is not necessary / is fixable by user interaction (pass dcs=15).

But what's still important is the weird "undefined" behavior in current master when dcs == 0.
We should definitely adjust master so that it doesn't try random data as USSD strings, like that 'ªQ [...] '.
For that reason I guess the quickest and most convenient is to merge your patch.

Actions #6

Updated by neels 8 months ago

  • Assignee changed from neels to fixeria
  • % Done changed from 0 to 70
Actions #7

Updated by fixeria 8 months ago

Good to hear!

I updated the commit message and marked the patch as active. Once merged, we can close this ticket.

Actions #8

Updated by fixeria 5 months ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)