sms bugfix

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.it
Mon Apr 4 15:27:57 UTC 2011


Hello

As said last Friday i have inspected the following bug: SMS with more 
than 160 chars from Nokia 3310 to iPhone works, but not the other way 
around.

It turns out, that once more the user_data_len is the problem. The 
problem is, that if we sent more than 160 chars a header with some 
information (user data header length, information element identifier, 
length, message identifier, message parts, message part number, fill 
bits) will be transmitted within the user_data. This is a problem 
because in my gsm_get_septet_len function i take the text-field from the 
database and count every extension character twice. In this special case 
it is possible that parts of the header data will be interpretet 
(decoded) as a extension character (in my case a pipe |). Therefore my 
function returns the wrong number of septets.

The best solution for that is to store the number of septets at the 
database (on the decoding process). Therefore i want to discuss if this 
is a suitable solution. If we don't want to change the structure of the 
database i could possible make a dirty hack (look if the "ud_hdr_ind" is 
set, get the "user data header length" (udhl) from the user_data, count 
the number of septets from "text - 1 - udhl - fill bits").
But i strongly recommend to change the database (i could do it).

Best Regards
Dennis Wehrle






More information about the OpenBSC mailing list