Hello
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