buggnokii - Bugs: bug #18587, bug in UDH length calculation in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #18587: bug in UDH length calculation in Concatenate Text Message

Submitted by:  None
Submitted on:  Tue 26 Dec 2006 07:04:07 PM UTC  
 
Category: libgnokiiSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Pawel Kot <pkot>
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Sun 05 Aug 2007 07:23:03 PM UTC, comment #11:

That is fixed as of 0.6.17 (I think).

Pawel Kot <pkot>
Project AdministratorIn charge of this item.
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

Anonymous
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

Pawel Kot <pkot>
Project AdministratorIn charge of this item.
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....

Anonymous
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

Anonymous
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

Anonymous
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;

Anonymous
Tue 26 Dec 2006 11:09:26 PM UTC, comment #4:

AT driver
with siemens GSM box

Alain

Anonymous
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

Pawel Kot <pkot>
Project AdministratorIn charge of this item.
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

Anonymous
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

Pawel Kot <pkot>
Project AdministratorIn charge of this item.
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

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pkot (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 05 Aug 2007 07:23:03 PM UTCpkotStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Sat 06 Jan 2007 10:53:41 PM UTCpkotStatusConfirmed=>Ready For Test
    Wed 27 Dec 2006 12:06:59 AM UTCpkotStatusNone=>Confirmed
      Assigned toNone=>pkot

    Back to the top


    Powered by Savane 3.1-cleanup1