This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Dennis Wehrle openbsc at wehrle.itHello
Here it is. After some delay (sorry!) i've finished the sms-patch. As
already mentioned, i have changed the database-format for the SMS-table.
If you already have a database, you have to _drop_ the SMS-table!
If you have questions, please feel free to ask me.
Best Regards
Dennis Wehrle
On 18.03.2011 23:01, Dennis Wehrle wrote:
> Hello
>
> Our goal was to send status sms via the vty interface. But all of our
> sms were cropped. In contrast sms from one MS to another MS are
> displayed correctly (despite the fact, that the text at the database
> contains several '@' at the end / the user_data contains several
> zero-octets). Therefore i have inspect the code and found several bugs.
>
> The main problem is that the "user_data_len" is not correctly used. As
> per GSM 03.40, 9.2.3.16 TP‑User‑Data‑Length (TP‑UDL):
> "If the TP‑User‑Data is coded using the GSM 7 bit default alphabet,
> the TP‑User‑Data‑Length field gives an integer representation of the
> number of septets within the TP‑User‑Data field to follow."
>
> Currently the "user_data_len" contains the number of octets (returned
> from gsm_7bit_encode(...) at gsm_utils.c (libosmocore)).
> The big problem here is that this information is not unique, e.g.:
> 1.) 46 non-extension characters + 1 extension character => (46 * 7 bit
> + (1 * (2 * 7 bit))) / 8 bit = 42 octets
> 2.) 47 non-extension characters => (47 * 7 bit) / 8 bit = 41,125 = 42
> octets
> 3.) 48 non-extension characters => (48 * 7 bit) / 8 bit = 42 octects
>
> But the MS has to know the correct "user_data_len" to decode the
> correct number of characters.
> For this reason i updated the gsm_7bit_encode() function to return the
> correct number of septets. However sometimes it is needed to know the
> correct number of octets (e.g. at gsm_04_11.c: gsm340_gen_tpdu(...))
> => i added a function to gsm_utils.c named:
> uint8_t get_octet_len(const uint8_t sept_len)
>
>
> I have also fixed the problem, that the sms are wrongly stored /
> displayed on the database. But the solution on the function
> *sms_from_result(...) (at db.c) is not really "beautiful". This is
> because there exists no "user_data_len" field at the database. To
> store the right value for "user_data_len" (which is further needed) i
> have to get the length from the "text" field. Unfortunately this is
> not enough. If the text contains extension characters like {[]} etc.
> then the "user_data_len" has to be bigger because these characters
> needs two septets. Therefore i use a switch statement so search for
> these characters. A better solution for that is to store the right
> "user_data_len" to the database (on the encoding / decoding
> procedure). But i don't know if this is a suitable solution for all of
> you (because you have to change your database structure etc.).
>
>
> Best Regards
> Dennis Wehrle
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sms_libosmocore.patch
Type: text/x-patch
Size: 18678 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110707/9a882abf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sms_openbsc.patch
Type: text/x-patch
Size: 18944 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110707/9a882abf/attachment-0001.bin>