Sun 05 Aug 2007 07:23:03 PM UTC, comment #11:
That is fixed as of 0.6.17 (I think).
|
Wed 27 Dec 2006 06:33:52 AM UTC, comment #10:
Well but take care about this:
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. If the 7bit default-alphabet extension mechanism is used within the TP-User-Data (see GSM 03.38), the actual number of characters in the message will be less than the number of septets. If a TP-User-Data-Header field is present, then the TP-User-Data-Length value is the sum of the number of septets in the TP-User-Data-Header field (including any padding) and the number of septets in the TP-User-Data field which follows. See figure 9.2.3.24.(a).If the TP-User-Data is coded using 8-bit data, the TP-User-Data-Length field gives an integer representation of the number of octets within the TP-User-Data field to follow. If a TP-User-Data-Header field is present, then the TP-User-Data-Length value is the sum of the number of octets in the TP-User-Data-Header field and the number of octets in the TP-User-Data field which follows. See figure 9.2.3.24.(b). If the TP-User-Data is coded using UCS2 [24] data, the TP-User-Data-Length field gives an integer representation of the number of octets within the TP-User-Data field to follow. If a TP-User-Data-Header field is present, then the TP-User-Data-Length value is the sum of the number of octets in the TP-User-Data-Header field and the number of octets in the TP-User-Data field which follows. See figure 9.2.3.24.(b). If the TP-User-Data is coded using compressed GSM 7 bit default alphabet or compressed 8 bit data or compressed UCS2 [24] data, the TP-User-Data-Length field gives an integer representation of the number of octets after compression within the TP-User-Data field to follow. If a TP-User-Data-Header field is present, then the TP-User-Data-Length value is the sum of the number of uncompressed octets in the TP-User-Data-Header field and the number of octets in the compressed TP-User-Data field which follows. See figure 9.2.3.24.(c) For other Data Coding Schemes, see GSM 03.38.If this field is zero, the TP-User-Data field will not be present.
regards,
Alain
|
Wed 27 Dec 2006 12:06:59 AM UTC, comment #9:
I have found that most drivers (all I checked but nk6510) use rawsms->length as the user data size. I need to review all of them and do the changes to have them in contigous state.
Thank you for raising this issue.
pkot
|
Wed 27 Dec 2006 12:01:49 AM UTC, comment #8:
I have seen the code in nokia.c
Well nokia is quite different from the standard given at ETSI...
The structure is different or perheps it is a side effect of the fbus mechanism... So I understand your problem when I purpose to fix the bug in gsm_sms.c So, the the better way to fix it is to modify the generic AT driver....
|
Tue 26 Dec 2006 11:36:06 PM UTC, comment #7:
Do you think it is better to do somethink like this:
req2[offset + 7] = (data->raw_sms->user_data_length + 6 ) *8 / 7 ;
Alain
|
Tue 26 Dec 2006 11:32:25 PM UTC, comment #6:
I confirm a driver bug ;-) but no only...
920 req2[offset + 4] = data->raw_sms->pid;
921 req2[offset + 5] = data->raw_sms->dcs;
922 req2[offset + 6] = 0xaa; /* Validity period */
923 req2[offset + 7] = data->raw_sms->length;
924 memcpy(req2 + offset + 8, data->raw_sms->user_data,
925 data->raw_sms->user_data_length);
offset+6 = AA ( As I can see in the Debug )
next byte is data->raw_sms->length;
Using user_data_length is not good I think because it is the length expressed in 8bit mode as needed for the memcpy function....
Alain
|
Tue 26 Dec 2006 11:20:57 PM UTC, comment #5:
It could be a problem of driver...
As I can see, the value used in AT for UDL id rawsms->length
Perhaps here:
req2[offset + 7] = data->raw_sms->length;
|
Tue 26 Dec 2006 11:09:26 PM UTC, comment #4:
AT driver
with siemens GSM box
Alain
|
Tue 26 Dec 2006 11:08:03 PM UTC, comment #3:
But UDL is stored in rawsms->user_data_length not in rawsms->length. And is calculated separately.
With which driver do you experience the problem? Sending long sms works fine with the phones I recently tested: nokia 6021 and nokia 6136.
pkot
|
Tue 26 Dec 2006 10:57:33 PM UTC, comment #2:
I repeat. this is wrong:
Structure is
UDL|UDHL|UDH|Fillbit|SM(7bit data)
where UDL is Total of Septets
UDHL is the length of UDH
So UDL is well len of UDHL + len of UDH + len of fill bit + len of SM !!!
The current algorythm just take care of the number of character.
The processing decoding could be different ( I do not have check the reception part )
See 3GPP TS 03.40 Version 7.5.0 Release 1998 at ETSI
If you don't believe me just make a test and you will see your message with missing character at the and of each part...
This fix works for me as expected and I hope to see it (or a better code and checked by other ) in the next release...
Alain Degreffe
|
Tue 26 Dec 2006 07:31:14 PM UTC, comment #1:
Hi,
I haven't analized it deeply yet but line 696 says:
rawsms->length, /* Length of the decoded text */
so it seems to be right as it is.
take care,
pkot
|
Tue 26 Dec 2006 07:04:07 PM UTC, original submission:
Hi,
I have already coded a patch fo alamin inthe past to support PDU format. So I have without much problem find the long text sms bug.
At line 1155 in common/gsm-sms.c, the code is:
rawsms->length = length;
This is wrong. This len should be the number of septets including the UDH so I purpose this line:
rawsms->length = ( (length * 7) + ( udh_length * 8 ) + 6 ) / 7 ;
This line will count the number of bit , and after number of septets. ( +6 is just a way to count correctly the number of septets with de fillbits mechanism ... )
Alain Degreffe
|