SMS Server Tools 3
This site is hosted by Kekekasvi.com
 Menu
Basic information:
Additional information:
Support:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

 Search
Custom Search

 Visitor locations
 
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Thu Mar 28, 2024 13:09
SMSTools3 Community » Help and support Bottom

[solved] Error in receiving messages ...

Login and Post Reply

Page:  1  2  Next

Author Post
Member
Registered:
Apr 2017
Location: Israel
Hello experts!

I am having issues receiving messages - instead of getting the right message data as it was sent, I am getting the below errors in the text file stored in the incoming directory :

[root@ecdist ~]# cat /var/spool/sms/incoming/GSM1.00GpMy
Error: Cannot decode PDU, see text part for details.
From:
Received: 17-04-30 23:51:40
Subject: GSM1
Modem: GSM1
IMSI: 425089110521863
Report: no
Alphabet: ISO
Length: 377
PDU: 0791795268720904040C917952726457570000714003610080034EB51A
Pos: ....-....*....-....*....-....*....-....*....-....*....-...~here(59)

First tried with PDU mode new (with CSA):
PDU ERROR: Position 59: While reading TP-UD (GSM text): string is too short
Partial content of text (2 characters, expected 78 ):
55

Next tried with PDU mode old (without CSA):
The PDU data (07) says that the message format is 3 which is not supported. Cannot decode.

No success. This PDU cannot be decoded. There is something wrong.


---

Information :

Operating system name and version:
Linux ecdist 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Version of smsd: Version 3.1.15
Smsd installed from: sources / package repository / from elsewhere... RPM
Name and model of a modem / phone: ZTE MF 831
Interface: serial / USB / some adapter... Modem - USB

---

Please assist , I am lost here :(

Thank you very much
Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Answer from the modem is broken.

Does this happen all the time and with all messages, or is this issue occasional?

You could use the loglevel = 7, and when the similar error happens, check from the log if there is remaining part of the answer received later, perhaps as an unexpected input. If the answer is received in more than one pieces and with remarkable delay between them, we should try to adjust some timeouts. If there are no remaining pieces of answer visible, the modem or serial interface may be broken.

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi Keke

Thank you for your reply

This behavior happens every time a sms is received.

I was able to receive sms successfully when using the same model of modem with the same sim in my Win PC - so, from what I can understand, it is not an issue with the modem or the sim.

Can you please suggest what should be set in the configuration file ?

(btw - log level is already set to 7)

Thank you very much

Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Please show the log, from the point where partial message is started to receive, to the point where incoming messages are checked next time, including modem's answer to the next checking. Then I can think what could be the solution.

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi

Please find below

Thank you
Yael




Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Thanks.

The answer from the modem is all what the modem was giving, as there is OK at the end of the answer and no any unexpected input is existing later.

I believe that this modem is just bad or broken. It also says that the length of the answer is 200 ( C8 ), but that is too high value in any case. And only one byte was given as answer, and then OK.

You wrote that "the same model of modem" was used on Windows, not the same modem? I think that you should try this same modem on windows to see how it works. And respectively try with smsd the modem which works properly on Windows.

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
On more thing, still swap the modems and test, but was your test message containing just "Hi"? And the message in the first post "Njj"?

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi,

Yes - my test message contained "Hi" (and the previous one was indeed Njj).

Unfortunately, I cannot access the web interface using the modem I am using in the Linux machine, as I have changed it to serial mode (using the following instructions : https://technicalexperiments.wordpress.com/2015/10/30/zte-mf831-for-use-with-openwrt-serial-modem-instead-of-cdc_ether/)

Because I can't access it from the web interface , I can't check receiving messages from my Win PC.

I have not performed the above configuration on the second modem I have (the same exact model) , so I can test it with the web interface.

BTW - when I used the web interface to receive messages to the second modem, the messages arrived to the Device storage - and on the modem used in the Linux, the messages arrive to the SIM storage.

Thanks
Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
The last test message as PDU ends with:
71504061428002C834 OK

It should be:
7150406142802102C834 OK

Service centre timestamp has only 6 octets, but it should have 7 octets. In your case timezone octet is missing. It should be 21 (UTC+03:00).

Can you find firmware upgrade for your modem, as the current firmware is bad?

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi Keke

I will check for a firmware update.
Anyway, I would like to update you that I was able to revert the configuration I described on my previous update - so my USB is back on Ethernet mode.
I was able to receive SMS to my SIM storage using the web interface - so it looks like after all it is not an issue with the modem or the SIM.

Please advise.

Thanks
Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Can you check what the modem answers to the following commands:

AT+CSMS?

AT+CSMS=?

If you stop the smsd, you can use the communication mode for testing: smsd -C GSM1

Also I would like to see the result of another test message which is much longer, like 30-50 characters. The previous test message was received as:

2017-05-04 23:15:29,7, GSM1: <- +CMGR: 0,,21 0791795268720914040C91795272645757000071504061428002C834 OK

What is in the log with longer message?

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi

This is the reply :

+CSMS: (0-1)

OK


Will post the result with the long (30 chars) message soon

Thanks
Yael

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi
please find below the log file for receiving a 42 chars SMS :

Thanks



Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi

I noticed that although I am choosing to work in test mode (using init2 in the conf file), the log still indicates that PDU is being used :

2017-05-05 02:13:38,6, GSM1: Selecting PDU mode
2017-05-05 02:13:38,7, GSM1: -> AT+CMGF=0

How can I avoid the PDU selection ?

Thanks
Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
What kind of test mode (using init2) do you mean?

There is a modem setting select_pdu_mode = no available. I just noticed that I have forgotten to write it into the manual. There is a title but no content. :(

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi

1. I meant text mode, not test mode.
2. Regarding select_pdu_mode - I have already tried using this parameter set to "no", but I still get the same errors, which indicates that the tool is still using PDU

Did you find anything interesting from the log output I provided ?

Please assist ....

Thanks
Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Okay :)

Text mode is not supported at all. It is too limited, and even when trying to use text mode, in some cases message is still received in PDU mode.

Some modems are always in PDU mode but do not accept the selection. It also saves little bit time, when the selection is not done and it is not required. That is why the setting is available.

I'm now on mobile and continue with this issue as soon as I'm back in the office.

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Your device may work properly, or may seem to work properly through the web interface, but the external AT command interface likely is broken.

When a message is read from the modem, there is a length of TPDU mentioned in the answer. For example, length of the TPDU in the post #5 is said to be 21, but in real it is only 20 octets. Timezone octet in the SMSC timestamp is missing, and it's against the GSM standard. In the post #13 the length is said to be 60, but it is only 58. In this case the message body is also broken.

As a solution by the side of smstools I was thinking a setting like smsc_timezone, which adds the timezone octet to the PDU, as it's always missing. Or, if the length of TPDU is one less than it was told to be, some missing_octet_is_smsc_timezone setting could be a workaround. But when the message body is broken too, there is no way to fix it.

When a timezone octet (21) is manually added to the PDU in post #13, the result is:
Quote
1234567890
1234567890
1234567890
YΘZΞÄ☹ÆΣEΣΘ@

I believe that this was not what you sent to the device, right?
Smstools also does not decode the message, because PDU is too short. One or more octets are missing in the text part too. Partial content is only shown.

It may sound strange that this kind of modem, especially the external AT command interface, exists. To make sure what is broken, you could make many sending/receiving tests, and this case with a message which is very long, for example containing 1234567890<LineFeed> 14 times.

1. From the modem send to it's own number.
2. From the modem send to your handset.
3. From your handset send to your handset.
4. From your handset send to the modem.

Depending on the results you will locate where the problem is, if the problem is not caused by the modem. If the modem seems to be a guilty, the SIM from another operator than the current operator could be tested too.

I'm sorry, this issue seems to go difficult. If the modem is the reason for problems, just throw it away or use it for other purposes than SMS messaging with external AT command interface.

Let me know how this issue continues or ends...

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi Keke

I have just tried sending a sms from the modem to itself , and still got the same PDU error as before.
I am enclosing the log from two send attempts - on the first one I sent a sms to a different device (my mobile phone), in which the the sms was received successfully, and on the second one I sent a sms from the modem to itself - which failed with the PDU error.

Can you please have a look and tell me what you think ?

Thanks
Yael



Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
First I think that your modem seems to be very slow.

Secondly, your SMS gets delivered even when "Type Of Address" is wrong. Likely there is some "detection" in the Service Center, but usually international format should be used. In your case a global setting national_prefixes = 0 is recommended. When sending to 05xxx, the number is said to be in "national format".

When the modem received a message, timezone octet was missing again. Text itself was correct, but it was very short. I recommended to use long text, near to 150 characters, to see if the text part always gets broken.

As your SIM's are from two different operators, I suggest to test sending to itself with the SIM from your handset in the modem.

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi

After using a different SIM in the modem, from a different operator , the PDU error message is still happening every time a sms is received

Any clue ? :(

Thanks
Yael

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Edit the src/pdu.c. Search for // Time zone and you are on the line 1262:

              if (!(*err_str))
              {
                Src_Pointer += 6;
                // Time zone is not used but bytes are checked:
                if (octet2bin_check(Src_Pointer) < 0)
                  pdu_error(err_str, 0, Src_Pointer -full_pdu, 2,
                            "Invalid character(s) in Time Zone of Service Centre Time Stamp: \"%.2s\"", Src_Pointer);
                else
                  Src_Pointer += 2;
              }
 
'c' Syntax Highlight powered by GeSHi


Change the line where is just else, add if (0) to the end:

                else if (0)
                  Src_Pointer += 2;
              }
 
'c' Syntax Highlight powered by GeSHi


With this change you should receive short messages properly, but with long text your modem still breaks the SMS and nothing can be done for it. Also status reports likely do not work.

Try to send/receive a SMS containing 800 characters, which is received in 5 parts. Likely you will see that the message body is broken, and next you should throw your bad modem away.

Member
Registered:
Apr 2017
Location: Israel
Topic owner
Hi

Thank you very very much for your time ,Keke.
It is working perfectly now!

We need to send only short messages , so the long messages is no problem .

Thank you very much again!

Thanks
Yael

Member
Registered:
Aug 2023
Location: Germany
Hi,

I habe currently the same problem. I just tried everything in this post, but had no luck to get it to work. I'm using the Huawei/Brovit E3372-325 stick.

What I'm trying to achieve:
- sending commands (Reboot, Restart, Reconnect, Test) to an Raspi
- the command should be checked and then some action should be done

I'm getting always the following error:
Quote
First tried with PDU mode new (with CSA):#012PDU ERROR: Position 19,2: Invalid sender address length: "0d"#012#012Next tried with PDU mode old (without CSA):#012The PDU data (07) says that the message format is 3 which is not supported. Cannot decode.#012#012No success. This PDU cannot be decoded. There is something wrong.

Maybe someone has an idea?

Thanks
Carsten

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
It would be useful to see a log file of receiving a message using loglevel=7.

Login and Post Reply

Page:  1  2  Next

SMSTools3 Community » Help and support Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.