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. Sat Apr 20, 2024 14:46
SMSTools3 Community » Help and support Bottom

smstools can't delete first message on sim, which will never read next

Login and Post Reply

Page:  1

Author Post
Member
Registered:
Apr 2017
Location: Österreich, Austria
Operating system name and version:
Model ZBT-WG3526 (16M)
Firmware Version OpenWrt SNAPSHOT r6880-aadca03 / LuCI Master (git-18.133.37847-2f0f456)
Kernel Version 4.14.37

Version of smsd: Version 3.1.21
Smsd installed from: repo of openwrt (trunk) => opkg install smstools3
Name and model of a modem / phone: HUAWEI ME909u-521 LTE LGA Module
Interface: /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2, /dev/ttyUSB3
=> highest id used for smstools


hello,

as the topic was closed ... see: http://smstools3.kekekasvi.com/topic.php?id=432

i have same problem, that sometimes i get a corrupted message (as I'm also testing to receive binary SMS, which are splitted into multiple parts .. or for whatever reason .. :(
anyhow ...

sometimes it happens that a message on the sim can't be read ...
then it only hangs in logs .. and getting time out .. eg:



as you can see there is a 1 message in storage, but it can't read .. tried also to change timeout for read .. was also not working ....

the only chance what i had was to delete this corrupted MSG manually via "smsd -C GSM"

then tried also to read again manually ....
AT+CMGR=0

no answer .....

then i tried to delete the message,
via:
AT+CMGD=0
and got <= OK

so far, everything fine ....
but ... as this 1 message is blocking all other new incomming message :(
that means the messages are arraiving to the storage, but as the first message (id1=#0) can't be read, it will never go to next message #1, so i miss all messages, finally the 20 storage id's willb e filled up, and then fully can'T get messages to storage, too :(

is it anyhow possible to handle such kind of problem ?
eg: if a message can't be read, then try to delete it via smstools.. or try to read next message ?
or to ignore if a message can'T be read and try to read next message .. something like that ...

is there such kind of options on smstools config settings ?

cu Erwin

Member
Registered:
Apr 2017
Location: Österreich, Austria
Topic owner
FYI ...
after deleting manually ... then started smstools again .. and all is working fine ...and send new message

OK


so, i have to think about to check anyhow if there are messages hanging which can't be read to try deleting them ..
any idea howto automatically handled by SMSTOOLS3 ?

cu Erwin

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Please test your device with check_memory_method = 31.

If it gets an error, add this setting: cmgl_value = 0.

Member
Registered:
Apr 2017
Location: Österreich, Austria
Topic owner
Mama mia ...admin should be renamed to "amazing keke" !!!!
I made so many tests with different mem check options, but i have overseen that cmgl needs to be set.. As you mentioned, i had to use cmgl 0 :)

Now, i tested with new settings as recommended from you, and now:
Corrupted 2 (hanging) sms where deleted and new sms are working.

On the restart, it purged/deleted the blocked sms and everything in.log looks perfect .

Thx a lot !!!!!

Member
Registered:
Apr 2017
Location: Österreich, Austria
Topic owner
hmm, only to be sure:
with check = 31
i got on new SMS:



it seems to be, that it works better with: 3

modem: HUAWEI ME909u-521 LTE LGA Module (in router: ZBT WG-3526)

my smsd.conf now:


Member
Registered:
Apr 2017
Location: Österreich, Austria
Topic owner
hmm, seems to be not that easy ... i need to test more in detail to see why i get always an alarm handler :(

in he doc of huawei 909 i see:



Member
Registered:
Apr 2017
Location: Österreich, Austria
Topic owner
finally, i figured out, that the real problem is, that the "CMGR" do not read the message from storage ..
that means, if the message is very short, then it works.
BUT if the message are longer (concatenated messages) => AT+CMGR always failing ... strange ....
#######
after a break, i checked if the SIM is broken and tried it on a tablet ... and all hanging 20 messages were arrarived and loaded by the tablet to messanger ...
hmm, so, SIM card is OK ...
##
mem_check_method ...
i checked all combinations ...
finally, only 0,1,2 were working ...(if the right device will be used, what i will explain below)
so, I'm using the "2" for huawei me909
###
then i set my focus on parameter howto read from device ....
played around with speed .. and going to 9600 ... but also makes not a real difference ...

####
DEVICE => ??

normally from system (lede project / wrt - linux 3.14)
the udev is creating the modem device links to:
/dev/ttyUSB0 , /dev/ttyUSB1, /dev/ttyUSB2, /dev/ttyUSB3

using /dev/ttyUSB0 for 3g/4g conenction.

as i have sometimes the problem, that the device will be reloaded by the kernel and the udev is then making:
/dev/ttyUSB0 , /dev/ttyUSB1, / dev/ttyUSB3, /dev/ttyUSB4
it is hard to handle that by smstools3 as i need to use the "/dev/ttyUSB2" (/dev/ttyUSB3 can't read long messages, too)

so, i thought i can make simple "ln -s ...." with a if/else script and using the symlink to 2nd highest number

somewhere i read about that i should use the highest number .... but as my tests have shown, on /dev/ttyUSB3 i can not read long messages (concatenated msg's)

####
conclusion: i use:
check_memory_method = 2
device = /dev/modem_sms (which is a symlink to /dev/ttyUSB2)


i have no clue why the /dev/ttyUSB3 is not reading if a message is longer, but that is the case after playing several hours around with it.

maybe that helps also others which are having problems.
thx, this topic can be closed i guess.

cu Erwin

Login and Post Reply

Page:  1

SMSTools3 Community » Help and support Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.