Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

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?

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.

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.

Good to hear!

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