search

mgaman / PDUlib

Encode/Decode PDU strings for use with most GSM modems. Both 7 bit and 16 bit alphabets are supported.
GNU Lesser General Public License v2.1
22 stars 10 forks source link

decoding Problem #23

Closed amir-skn closed 1 year ago

amir-skn commented 2 years ago

Hello, and thank you for this helpful library.

I'm using sim800 and esp32. The platform is Arduino on PlatformIO.

I faced a problem when decoding SMS from a specific number. I guess it is using a different PDU scheme. Note that my SMS contains both Arabic and English characters.

The first message which is successfully being decoded is :

06918919015000 400C91 891982102030 00082270701161818 18C050003510201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

The second message which PDUlib throws an "decoding rejected" for is:

06918919015000 640A80 8905003470 00082270701152148 18C050003CD0201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

Both messages are continuous. I just segmented them into lines to better indicate the differences.

EliasA97 commented 2 years ago

It appears to be both of them are the same message. It doesn't contain any Arabic characters, at least it doesn't show them when I decoded it on an online converter. The second message doesn't contain your country's prefix number eg. +40.

Your first message's senders number is +9800000000 and the second message's is 9800000000. (Obviously the zeros are for your number's privacy.)

Check again when you send the message on the SIM800

P.S. I'm not the developer of the library. I just help you because I got much help from David (the developer), and I want to contribute with that way.

mgaman commented 2 years ago

Hi Amir, The first thing that I see is that these are parts of a multi-part message. Support for multi-part started from v0.5.4 of my library. What version are you using? Secondly are these 2 messages supposed to be both part of the same multi-part message? I can see that they are not.

From my analysis of the 1st message I get: Part 1 of 2 part message SCA number: Source number: Timestamp: 22070711161818 Text: @.**@*.**@*.***

My analysis of the 2nd message fails when decoding the Source phone number as it has an address type I do not recognize i.e. not a national or international number. The spec has lots more that I haven't implemented. Let me look into it.

Best Regards David

On Thu, Jul 7, 2022 at 10:06 AM Amir Sk @.***> wrote:

Hello, and thank you for this helpful library.

I'm using sim800 and esp32. The platform is Arduino on PlatformIO.

I faced a problem when decoding SMS from a specific number. I guess it is using a different PDU scheme. Note that my SMS contains both Arabic and English characters.

The first message which is successfully being decoded is :

06918919015000 400C91 891982102030 00082270701161818

18C050003510201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

The second message which PDUlib throws an "decoding rejected" for is:

06918919015000 640A80 8905003470 00082270701152148

18C050003CD0201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

Both messages are continuous. I just segmented them into lines to better indicate the differences.

— Reply to this email directly, view it on GitHub https://github.com/mgaman/PDUlib/issues/23, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3KSTRR6DLXTY2UELAI2BTVSZ6YJANCNFSM524IQ3XA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

mgaman commented 2 years ago

Well, I found the problem in the 2nd message. I refer you to https://en.wikipedia.org/wiki/GSM_03.40#Addresses The beginning of the SCA number is 06 91 and if you read the above link that translates to a 6 character, international number The beginning of the Source number is 0A 80. That translates to a 10 character, unknown type of number. However, your problem raises a valid issue. My code has a policy of bailing out when any problem occurs. Maybe I should add an option for "LAX" mode i.e. carry on even though some parts are in error.

Best Regards David

On Thu, Jul 7, 2022 at 10:06 AM Amir Sk @.***> wrote:

Hello, and thank you for this helpful library.

I'm using sim800 and esp32. The platform is Arduino on PlatformIO.

I faced a problem when decoding SMS from a specific number. I guess it is using a different PDU scheme. Note that my SMS contains both Arabic and English characters.

The first message which is successfully being decoded is :

06918919015000 400C91 891982102030 00082270701161818

18C050003510201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

The second message which PDUlib throws an "decoding rejected" for is:

06918919015000 640A80 8905003470 00082270701152148

18C050003CD0201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

Both messages are continuous. I just segmented them into lines to better indicate the differences.

— Reply to this email directly, view it on GitHub https://github.com/mgaman/PDUlib/issues/23, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3KSTRR6DLXTY2UELAI2BTVSZ6YJANCNFSM524IQ3XA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

amir-skn commented 2 years ago

I appreciate your consideration! You are right! I read the link that you provided. It says it's an unknown number and part of the national numbering plan. Am I getting it right? What is weird for me is that SIM800 itself successfully provides the number. It is also true for various online PDU decoding websites. Like what you are planning to do, They ignore the unknown TON and report the number. I will be glad to help. I actually have gone through your code and found that problem arise in decodePDU ➤decodeAddress(&pdu[index], addressBuff, NIBBLES); ➤ switch ((adt & TON_MASK) >> TON_OFFSET) ➤ default case. Your library was a huge help. I'm using the latest version, which is 0.5.4.

mgaman commented 2 years ago

My current code bails out when there is an error in one of the fields. This is of course essential when Encoding as an incorrect message format cannot be sent. However it might make sense to be less stringent for Decoding. I already started along that path on 0.5.5. When decoding a message that is too long to fit in the buffer work area the code flags an error but also delivers that part of the message that was decoded. The code works as intended so this is not a bug. However as an improvement is possible I will leave this issue open.

mgaman commented 1 year ago

This is a multi-part message and is handled correctly from release 0..5.5