SMS received one bit shifted (Huawei - E1750)

[GoogleCodeExporter]

Hi,

Noticed that some 7-bit SMS got shifted by one bit. I needed to skip the first 
bit in order to read the SMS by using a custom script.

Is this a bug in the SMS parsing of chan-dongle?

--HPS

BASE64 encoded data received:

echo "EENlQVhLZ2lBZm" | b64decode -rm | ./a.out | hexdump -C | less

Source code for a.out:

#include <stdio.h>
#include <stdint.h>

int main()
{
    int c;
    uint32_t temp = 0;
    uint8_t bits = 0;

    while ((c = getchar()) != -1) {
        temp |= (uint8_t)c << bits;
        bits += 7;
        while (bits >= 8) {
            printf("%c", (temp >> 1) & 0x7F);
            bits -= 7;
            temp >>= 7;
        }
    }
    return (0);
}

Original issue reported on code.google.com by hsela...@gmail.com on 28 Aug 2014 at 7:01

[GoogleCodeExporter]

Have sample of CGMR or PDU received ?

Original comment by bg_...@mail.ru on 31 Aug 2014 at 2:54

[GoogleCodeExporter]

Hi,

I have an AT command capture. It happens with Multi Part SMS only.

Can you send me your e-mail, hence the capture contains private information.

Thank you!

--HPS

Original comment by hsela...@gmail.com on 3 Sep 2014 at 11:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It appears that chan dongle does not support concatenated SMS messages. I've 
added some basic support for this. The most obvious difference is that the data 
payload is actually padded with a single bit. See:
http://en.wikipedia.org/wiki/Concatenated_SMS

Also I've added a check to remove extra bytes at the end of the HEX payload.

--HPS

Original comment by hsela...@gmail.com on 15 Sep 2014 at 4:47

Attachments:

• sms_multipart.diff

[GoogleCodeExporter]

ok. thanks for patch, will integrate later

Original comment by vas...@ngs.ru on 25 Sep 2014 at 6:14

[GoogleCodeExporter]

i have applied your patch  but i am unable to receive multipart messages and i 
have creatd issue 
https://code.google.com/p/asterisk-chan-dongle/issues/detail?id=186

are u able to receive multipart messages ?

have you solved problum ?

Original comment by shabbira...@gmail.com on 26 Oct 2014 at 9:54

[GoogleCodeExporter]

Yes, but there might be more ways to send multipart messages than the one I 
have covered.

--HPS

Original comment by hsela...@gmail.com on 26 Oct 2014 at 12:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,

Actually the udhl is a variable, so we need to get the length from the header 
itself. Please try the attached patch.

Thank you!

--HPS

Original comment by hsela...@gmail.com on 29 Oct 2014 at 7:42

Attachments:

• sms_multipart_updated.diff

[GoogleCodeExporter]

Dear @--HPS   i have aoolied your updated patch after reversing  
sms_multipart.diff
patch is not working and now  sms output in console is
[2014-10-29 16:21:51]  [ufone] Got SMS from Ufone: ' 3Z;=y
                                                            H=;=l,+,,K
                                                                          ,
                                                                           M
                                                                            '
and this is pdu 
07912933035011804409D055F3DB5D060000410192611264022A0807010300031A0202A09976D7E9
E5390B640FB3D364103DCD668364B3562CD692C1623417

i think this pdu will help you to solve  this issue 

Original comment by shabbira...@gmail.com on 29 Oct 2014 at 11:30

[GoogleCodeExporter]

Hi,

Updated patch once again. Please try and report back. Thank you!

--HPS

Original comment by hsela...@gmail.com on 29 Oct 2014 at 2:06

Attachments:

• multipart_updated.diff

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,

Did you "svn revert -R ." first?

The patch should apply cleanly!

--HPS

Original comment by hsela...@gmail.com on 29 Oct 2014 at 7:30

[GoogleCodeExporter]

From your chan_dongle-r42...patch I see you did not get all of my latest patch. 
Can you try to re-apply?

--HPS

Original comment by hsela...@gmail.com on 29 Oct 2014 at 7:50

[GoogleCodeExporter]

now i have downloaded  revision 34 from 
https://github.com/jstasiak/asterisk-chan-dongle/archive/asterisk11.zip   and 
applied ur patch 
[root@CENTOS asterisk-chan-dongle-asterisk11]# patch  < multipart_updated.diff 
patching file char_conv.c
Hunk #1 succeeded at 267 (offset 16 lines).
Hunk #2 succeeded at 351 (offset 16 lines).
patching file char_conv.h
patching file pdu.c
can't find file to patch at input line 275
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: test/parse.c
|===================================================================
|--- test/parse.c   (revision 38)
|+++ test/parse.c   (working copy)
--------------------------
File to patch: test/parse.c
patching file test/parse.c

and now it is doing totaly wrong 

Got SMS from 553: ''
wrong sender and sms is empty above
but sender is ufone  and sms is 'Minutes, valid till 11-11-2014.' 

Original comment by shabbira...@gmail.com on 29 Oct 2014 at 8:37

[GoogleCodeExporter]

i think it is doing wrong because sender address is alphabet
if i send multipart sms from number like +92xxxxxxxxxx  it is decoded 
successfully

Original comment by shabbira...@gmail.com on 29 Oct 2014 at 8:50

[GoogleCodeExporter]

Hi,

chan dongle will filter the incoming phone number. I don't know if alphabet 
characters are allowed ... I'll see if I can figure out this issue too.

--HPS

Original comment by hsela...@gmail.com on 29 Oct 2014 at 9:36

[GoogleCodeExporter]

Hi,

Here is one more patch you can try. When you send the wronly decoded PDU, can 
you also send the correctly decoded message?

Thanks!

--HPS

Original comment by hsela...@gmail.com on 2 Nov 2014 at 9:58

Attachments:

• sms_multipart_002.diff

[GoogleCodeExporter]

it is a fresh download and no one patch is applied
patch <  sms_multipart_002.diff 
make  
make install
1st pdu
0791293303501180400C91292143658709000041112071100202A00500031B0201906536FB0D4297
D9EC37085D66B3DF2010B2CC66BF41E8329BFD06A1CB6CF61B5966B3DF207499CD7E83D06536FB0D
0221CB6CF61B842EB3D96F10BACC66BF916536FB0D4297D9EC37085D66B3DF2010B2CC66BF41E832
9BFD06A1CB6CF61B5966B3DF207499CD7E83D06536FB0D0221CB6CF61B842EB3D96F10BACC66BF91
6536FB0D4297D9
above pdu decoded correct

2nd pdu
0791294305009071640DD0D432BBEC7ECB010008411120715094022C050003310202002000720061
00610074002000310032002000740061006B0020006800610069002E000D000A
Got SMS from 4B23##ACC7#A10: ' raat 12 tak hai.
only sender decoded wrong because i have not applied alphanumeric patch . 
message decoded correct, and message  encoding is in unicode

3rd pdu
0791293303201100440C91292143658709000041112071015102A00500031D0201906536FB0D0281
4020504C36A3D56C375C0E1693CD6835DB0D9783C564335ACD76C3E560201008842EB3D96F6499CD
7E83402010081493CD6835DB0D9783C564335ACD76C3E56031D98C56B3DD703918080402A1CB6CF6
1B5966B3DF2010080402C564335ACD76C3E56031D98C56B3DD7039584C36A3D56C375C0E06028140
E8329BFD4696D9
decoded correct ,  encoding   Default Alphabet

4th pdu  2nd part of sms
07912933035011804409D055F3DB5D060000411120712071022A080701030003990202A09976D7E9
E5390B640FB3D364103DCD668364B3562CD692C1623417

 Got SMS from 553: 'Pm]N^<NdLM
$6VV%Ff'                                                   DMM 
decoded wrong 
i hope u will solve this soon ,  thank u very much for ur work

Original comment by shabbira...@gmail.com on 2 Nov 2014 at 12:38

[GoogleCodeExporter]

Hi;

i have asked a question on  
http://stackoverflow.com/questions/26683540/explain-sms-udh-header08-07-01-03-00
-03-08-02-02  for understanding  udh header  if we add last two octet of udh 
header then it is readable(with 1 extra @ character in front of sms)
is it a problum about fill bits ?

Original comment by shabbira...@gmail.com on 5 Nov 2014 at 4:14

[GoogleCodeExporter]

Thank you!

I'll have a look and match the result with the parsing algorithm.

--HPS

Original comment by hsela...@gmail.com on 6 Nov 2014 at 8:12

[GoogleCodeExporter]

Hi,

Thanks for the stackoverflow article! It helped solve the mystery. It looks 
like the UDH affects the bit-shifting of the 7-bit characters afterwards. Not 
sure if UCS2 or native 7-bit needs this too. Anyway, please find updated patch, 
which also now make all tests pass!

Should apply cleanly to trunk of chan_dongle SVN.

Thank you!

Please commit when tested and all is OK!

--HPS

Original comment by hsela...@gmail.com on 28 Nov 2014 at 12:36

Attachments:

• sms_multipart.diff

[GoogleCodeExporter]

hi,
Thanks for ur latest patch , i have tested it today it is working fine but  
sender address is wrong ( Got SMS from 553)  instead  of ( Got SMS from Ufone)  
Thanks very much for ur hard work 

Original comment by shabbira...@gmail.com on 13 Dec 2014 at 8:25

[GoogleCodeExporter]

Hi, maybe that can be opened as a separate issue. Let's fix one issue at a time!

--HPS

Original comment by hsela...@gmail.com on 13 Dec 2014 at 10:20

[GoogleCodeExporter]

HI     --HPS

1. i have applied sms_multipart.diff
2.i have modified chan-dongle-alphanumeric-pdu.patch    from issue #17
and now my problum has been  solved  and now chan_dongle is able to parse 
multipart sms  with alphanumeric numbers 

below is patch  chan-dongle-alphanumeric-pdu.patch   

Original comment by shabbira...@gmail.com on 23 Dec 2014 at 6:53

Attachments:

• chan_dongle-alphanumeric-updated.patch

[GoogleCodeExporter]

and now it is confirmed that it is working  fine  so i have tried to commit
 svn commit -m "Fixed Issue #183 SMS received one bit shifted"
svn: Commit failed (details follow):
svn: Server sent unexpected return value (405 Method Not Allowed) in response 
to MKACTIVITY request for '/svn/!svn/act/9bd20a5d-d211-49bd-b52c-43cd7aec263f'

Original comment by shabbira...@gmail.com on 23 Dec 2014 at 6:56

[GoogleCodeExporter]

Hi,

I think you need a special svn checkout url, like svn+ssh://username@xxxxx/ 
before you are allowed to commit!

--HPS

Original comment by hsela...@gmail.com on 23 Dec 2014 at 10:19