[M] Change in osmo-hlr[master]: USSD: fix handling of ussd-DataCodingScheme != 0x0f

Attention is currently required from: neels. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hlr/+/33528 ) Change subject: USSD: fix handling of ussd-DataCodingScheme != 0x0f ...................................................................... Patch Set 2: (2 comments) File src/hlr_ussd.c: https://gerrit.osmocom.org/c/osmo-hlr/+/33528/comment/8f989f9b_4ed72202 PS2, Line 146: /* do not abort, attempt to decode as if it was '1111'B */ I don't have a strong opinion here. Reading the AT command reference documents of other modems (mostly Ericsson ones) I see `DCS 0x00` (German) is also the default for them. Passing `,15` all the time is annoying, so I thought it would not hurt if we ignore the language in the message initiating a USSD session. The language should not really matter for the initial request message, since the charset is usually limited to `[0-9*#]`. https://gerrit.osmocom.org/c/osmo-hlr/+/33528/comment/6a89be5b_6fc91ccd PS2, Line 150: req->ussd_data, (req->ussd_data_len * 8) / 7); I need to give you some historical context then. IIRC, prior to my patches dating back to 2018 neither the `ussd_data_dcs` field nor the `ussd_data[_len]` fields existed in `struct ss_request`. All we had is the `ussd_text` field, which may contain ASCII text or raw bytes depending on DCS. The `gsm0480_parse_facility_ie()` does call `gsm_7bit_decode_n_ussd()` internally if `DCS == 0x0f`, otherwise it does `memcpy()` raw bytes to the `ussd_text` field. In 2018 it was decided to deprecate the `ussd_text` field and expose the raw bytes + DCS to the API user, so that the end user can perform decoding if needed and as needed. The internal call to `gsm_7bit_decode_n_ussd()` was preserved for backwards compatibility. When adding the SS/USSD support to osmo-hlr, Harald used the old `ussd_text` field, and this is where the problem is. As I said above, despite having `text` in the name, this field may contain either an ASCII string or raw bytes. So I decided to move away from using it and migrate to `ussd_data[_len]` fields in this patch. The simplest thing I could do is to not touch the code and keep using the old `ussd_text` field, and ensure that DCS is exactly 0x0f before doing that. But I wanted to make code more tolerant to DCS values != 0x0f and still parse the requests if the language != 15. -- To view, visit https://gerrit.osmocom.org/c/osmo-hlr/+/33528 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hlr Gerrit-Branch: master Gerrit-Change-Id: Ib7bac660b1a7942adcfbe7b14f162c95061a25db Gerrit-Change-Number: 33528 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Comment-Date: Wed, 05 Jul 2023 13:34:15 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: comment