SMS defects

[GoogleCodeExporter]

chan_datacard: Datacard Channel Driver, Version 1.0, Revision 252
datacard model E1550
firmware: 11.608.14.15.311
kernel:2.6.32-26-server
CPU: x64
ubuntu 10.10.1
if received sms > 150 char, datacard crashes ... ttyUSB dissapears, need 
server restart or it recover itself after few h
Note: this didn't happned on the 
https://www.makhutov.org/svn/chan_datacard/trunk/
on their driver when sms was bigger then 150 char was arrived as 2 sms's but in 
a strange format (not decoded)

if send sms more then 150 char > error again.

Original issue reported on code.google.com by florin.m...@gmail.com on 7 Dec 2010 at 6:25

[GoogleCodeExporter]

confirmed (more than 150 character):

Executing [sms@de-modem:1] Verbose("Local/sms@de-modem-c401;1", "Incoming SMS 
from +34699112233 
_YCAbkKAhCYAJgiCg]@2_AJgi_sAheK[K]IC[K]iKADSK]ABgSAbkKA\_AZKA`kKI_AbkKUCeAHKAX_A
DSK]AbkKAZKAX_AJgi_sA`CgC]I_AJgi_gAHSCgAHKACmSICIKgAJ]AZSAFCgC]@(KAX_AH") in 
new stack
Incoming SMS from +34699112233 
_YCAbkKAhCYAJgiCg]@2_AJgi_sAheK[K]IC[K]iKADSK]ABgSAbkKA_AZKA`kKI_AbkKUCeAHKAX_AD
SK]AbkKAZKAX_AJgi_sA`CgC]I_AJgi_gAHSCgAHKACmSICIKgAJ]AZSAFCgC]@(KAX_AH

Original comment by pag...@gmail.com on 7 Dec 2010 at 6:48

[GoogleCodeExporter]

Also after a while i get sms full error and need to issue a
datacard cmd datacard0 AT+CMGD=0
datacard cmd datacard0 AT+CMGD=1
datacard cmd datacard0 AT+CMGD=2
datacard cmd datacard0 AT+CMGD=3
datacard cmd datacard0 AT+CMGD=4
and this bring it back to OK to receive more sms's ;)

Original comment by florin.m...@gmail.com on 7 Dec 2010 at 6:56

[GoogleCodeExporter]

datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
9999999999000000000011111111112222222222333333333344444444445555555555
[datacard0] SMS queued for send
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
[datacard0] SMS queued for send
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
7777777777
[datacard0] SMS queued for send
[Dec  7 18:59:32] ERROR[2077]: at_queue.c:243 try_write: [datacard0] Error  
command 'SMSTEXT' expected response 'OK' expired, cancel
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
[datacard0] SMS queued for send
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
7
[datacard0] SMS queued for send
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
77
[datacard0] SMS queued for send
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
777
[datacard0] SMS queued for send
[Dec  7 18:59:49] ERROR[2077]: at_queue.c:243 try_write: [datacard0] Error  
command 'SMSTEXT' expected response 'OK' expired, cancel
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
77
[datacard0] SMS queued for send
gamble*CLI> datacard sms datacard0 07111000003 
11111111112222222222333333333344444444445555555555666666666677777777778888888888
99999999990000000000111111111122222222223333333333444444444455555555556666666666
777

seems nothing happening ;)

Original comment by florin.m...@gmail.com on 7 Dec 2010 at 7:02

[GoogleCodeExporter]

in PDU mode limit for outgoing SMS is 70 UCS-2 symbols.

TODO: check message charset covered 7 bits and send as GSM 7Bit encoded.

Original comment by bg_...@mail.ru on 7 Dec 2010 at 7:23

• Changed state: Accepted

[GoogleCodeExporter]

Test results for TEXT mode with "Use UCS-2 encoding      : Yes"

95 symbols OK
100 symbols +CMS ERROR: 305
98 symbols OK
99 symbols +CMS ERROR: 305
99 symbols OK

number and message same :)

:)

Original comment by bg_...@mail.ru on 7 Dec 2010 at 7:45

[GoogleCodeExporter]

It about send side 

Original comment by bg_...@mail.ru on 7 Dec 2010 at 7:46

[GoogleCodeExporter]

nothing sent! card stuck ! had to reset it lots of times till back working!

Original comment by florin.m...@gmail.com on 7 Dec 2010 at 7:54

[GoogleCodeExporter]

for 121 symbol modem not response 
and still in SMS prompt infinite until i wrote 0x1B (ESCAPE) to modem manually.

Original comment by bg_...@mail.ru on 7 Dec 2010 at 7:58

[GoogleCodeExporter]

133 symbols +CMS ERROR: 305
134 symbols NO RESPONSE and always SMS prompt

Original comment by bg_...@mail.ru on 7 Dec 2010 at 8:09

[GoogleCodeExporter]

in PDU mode receiving is ok
but in TEXT mode 

manually 
$ cat /dev/ttyUSB2 > raw.read
message sent
don't break cat 
look to raw.read, ok +CMTI: "ME",3 message received

try to read 
$ echo -e "AT+CMGR=3\r" >  /dev/ttyUSB2

device USB detached attach again 
look to raw.read, contain "OK" and zeros 

Ok, yet another HW BUG found 

Run r181  of https://www.makhutov.org/svn/chan_datacard/trunk/
+CMTI: "ME",4
]
[Dec  8 04:07:44] DEBUG[32570] __at_response.c: [datacard0] Incoming SMS message
[Dec  8 04:07:44] DEBUG[32570] __at_send.c: [datacard0] [AT+CMGR=4
]
[Dec  8 04:07:44] DEBUG[32570] __at_fifo_queue.c: [datacard0] add command 
'AT+CMGR' expected response '+CMGR'
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] receive 2048 byte, used 
2048, free 0, read 0, write 2048
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] [ATZ
ODE:3,3
,3
0,0,0,87
]
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] multiline response
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] multiline response
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] multiline response
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] receive 2048 byte, used 
2048, free 0, read 0, write 2048
[Dec  8 04:07:50] DEBUG[32570] __at_read.c: [datacard0] [J ]
[Dec  8 04:07:50] DEBUG[32570] __at_fifo_queue.c: [datacard0] remove command 
'AT+CMGR' expected response '+CMGR'
[Dec  8 04:07:51] WARNING[32563] chan_datacard.c: Unable to open '/dev/ttyUSB2'
[Dec  8 04:08:07] DEBUG[32569] __at_read.c: [datacard1] receive 27 byte, used 
27, free 2021, read 0, write 27
[Dec  8 04:08:07] DEBUG[32569] __at_read.c: [datacard1] [

Original comment by bg_...@mail.ru on 7 Dec 2010 at 10:08

[GoogleCodeExporter]

on i686 no crash :(

Original comment by bg_...@mail.ru on 7 Dec 2010 at 11:30

[GoogleCodeExporter]

> Note: this didn't happned on the 
https://www.makhutov.org/svn/chan_datacard/trunk/
Not true, Makhutov thought disablesms=yes for avoid reading too long SMS, which 
down device :)))

Original comment by bg_...@mail.ru on 8 Dec 2010 at 8:32

[GoogleCodeExporter]

is NOT hardware fault.
I've just checked the asterisk/huawei implementations from here:
http://asterisk-es-rsp.irontec.com/svn/asterisk-es-rsp/team/Odicha/rsp_gsm/
and look the receive sms bigger then 150 char:
GSM 3: > ATE0
GSM 3: < OK , 2 >
GSM 3: smsc_len = 7
GSM 3: smsc_toa = 0x91
GSM 3: smsc_number = +447958879880
GSM 3: sender_len = 12
GSM 3: sender_toa = 0x91
GSM 3: sender_number = +44XXXX000003
GSM 3: protocol identifier = 0
GSM 3: data coding scheme = 0
GSM 3: timestamp = 10121414445000
GSM 3: user data length = 160
GSM 3: user_data = 
050003510201E7E8397A8E9EA3E7E8397A3E47A3E773F41C3D47CFD1F3397A8E46A3E7E2397A8E46
CFD173F41C3D9FA3E7E8F91C3D47CFD173F41C3D47CFD173F41C3D47CFE7E8397A8E9EA3E7E8397A
8E9EA3E7E8F91C3D47CFE7E8F91C3D47CFD173347A8E9EA3E7E8397A8E46CFE7E8397A8E9EA3E7E8
F91C3D47A3E7683
GSM 3: user_data_8bit =
    -- SMS from +44xxxx000003 received on channel 3. (Text: ) (PDU: 0791449785788908440C9144xxxx000030000001214141440500A0050003510201E7E8397A8E9EA3E7E8397A3E47A3E773F41C3D47CFD1F3397A8E46A3E7E2397A8E46CFD173F41C3D9FA3E7E8F91C3D47CFD173F41C3D47CFD173F41C3D47CFE7E8397A8E9EA3E7E8397A8E9EA3E7E8F91C3D47CFE7E8F91C3D47CFD17334)
GSM 3: < OK , 2 >PuTTY
GSM 3: < ^RSSI:12 , 8 >
GSM 3: < +CMTI: "SM",4 , 13 >
GSM 3: > AT+CMGF=0;+CMGL
GSM 3: < +CMGL: 4,0,,47 , 14 >
GSM 3: > AT+CNMI=1,1,0,2,0
GSM 3: < 
0791449785788908640C9144xxxx00003000000121414144150020050003510202D1F3F99C8C26A3
C96832194D4693D16434194D26ABC9 , 110 >
GSM 3: > ATE0uTTYPuTTY
GSM 3: < OK , 2 >PuTTY
GSM 3: smsc_len = 7 TY
GSM 3: smsc_toa = 0x91
GSM 3: smsc_number = +447958879880
GSM 3: sender_len = 12
GSM 3: sender_toa = 0x91
GSM 3: sender_number = +44xxxx000003
GSM 3: protocol identifier = 0
GSM 3: data coding scheme = 0
GSM 3: timestamp = 10121414445100
GSM 3: user data length = 32
GSM 3: user_data = 050003510202D1F3F99C8C26A3C96832194D4693D16434194D26ABC9
GSM 3: user_data_8bit =
    -- SMS from +44xxxx000003 received on channel 3. (Text: ) (PDU: 0791449785788908640C9144xxxx00003000000121414144150020050003510202D1F3F99C8C26A3C96832194D4693D16434194D26ABC9)
GSM 3: < OK , 2 >PuTTYPuTTYPuTTY
GSM 3: < ^RSSI:9 , 7 >PuTTYPuTTY
GSM 1: smsc_len = 7 TYPuTTYPuTTY
GSM 1: smsc_toa = 0x91 uTTYPuTTY
GSM 1: smsc_number = +447802000332
GSM 1: sender_len = 11 uTTYPuTTY
GSM 1: sender_toa = 0xd0 TYPuTTY
GSM 1: sender_number = 8391C4603910
GSM 1: protocol identifier = 0 Y
GSM 1: data coding scheme = 0xf5
GSM 1: timestamp = 10121414371600
GSM 1: user data length = 140 TY
GSM 1: user_data = 
0B05040B8423F100034D02017906226170706C69636174696F6E2F766E642E7761702E6D6D732D6D
65737361676500AF848C8298433154516542476C4B4577426B414146524C41414141637741414271
384141414141008D908919802B3434373735363233353337342F545950453D504C4D4E008A808E02
61A88805810303F
GSM 1: user_data_8bit = TTYPuTTY

X@pHx
    -- SMS from 8391C4603910 received on channel 1. (Text:

Original comment by florin.m...@gmail.com on 14 Dec 2010 at 2:48

[GoogleCodeExporter]

i like their implementation and seems a bit more stable !!! Using chan_dahdi!
read
http://odicha.net/?p=10
and
http://odicha.net/?p=14

(use google translate as i did to understand it ;) )

Original comment by florin.m...@gmail.com on 14 Dec 2010 at 2:51

[GoogleCodeExporter]

Odicha is a friend of mine. He is a very good developer but haven't so much 
time to finish his work. I can confirm, his implementation of sms (based on 
junghans libgsmat) seems to work ok in PDU mode, but I did not test so much.

His work focused in dahdi integration of junghans GSM. The problem is that 
it's, by far, much more simple than chan_datacard. Initially, he tried to do 
something similar (libsebi). Libsebi was the first effort (even before 
chan_datacard) to integrate huawei modems, but then it was given up, and 
started rsp_gsm.  Integration with chan_dahdi looks atractive, but now this 
datacard module is much more capable than rsp_gsm.

Original comment by pag...@gmail.com on 14 Dec 2010 at 3:16

[GoogleCodeExporter]

i understand this, but chan_datacard rely on option module which has some major 
bugs (datacard disconnects on bigger sms receive, etc etc), while his idea of 
implementation is a bit better (his own driver). Not managed yet to crash the 
datacard :)
Looking into the stability of the thing first and the extra feautures ;)

Original comment by florin.m...@gmail.com on 14 Dec 2010 at 3:21

[GoogleCodeExporter]

some literature about longer the 160 char sms's :
http://mobiletidings.com/2009/02/18/combining-sms-messages/

Original comment by florin.m...@gmail.com on 14 Dec 2010 at 5:36

[GoogleCodeExporter]

4  florin.mandache
Its firmware bug i think
i talk 'try read long sms in TEXT mode'
i see AT+CMGF=0 PDU mode

no troubles in PDU mode,
please use option

smsaspdu=yes

Original comment by bg_...@mail.ru on 21 Dec 2010 at 3:32

[GoogleCodeExporter]

still NOT working :
 Error parsing SMS text: 546869732069732061207465737420736D7320736A736A736A646A666920646672756675667566722066686A75666965776964636A656B73786364666A647265732066646A646672657364786366726577736466206666666666666666666666666666666666666666666666662065777971777368647565776173786463667667206664657378646366726577736466726520666465777378
[Dec 28 21:20:32] ERROR[22653]: at_response.c:1203 at_response_cmgr: 
[datacard1] Error parsing SMS text: 
416E67696520206920616D2020626567696E6E696E672020746F20776F6E64657220206172652020
796F752061207265616C206769726C2020626563617573652020796F7520206E6576657220746578
74206D6520206261636B20202074657874206D65206261636B206E6F7720206F6E20796F75722020
6F776E2070686F6E65206E756D6265722020746F207361792020692077696C6C20
[Dec 28 21:20:36] ERROR[22653]: at_response.c:1203 at_response_cmgr: 
[datacard1] Error parsing SMS text: 
206D6565742020796F7520746F6D6F72726F77202020617420746573636F20202020617420313233
30202020202020202077652077696C6C20676F20666F722061206472696E6B20202020636F6D6520
6F6E207468656E2020616E6769652020202074657874206D65206E6F772020202020737465766520
7820782078207820202020202020202020202020202020

and i set smsaspdu=yes !

Original comment by florin.m...@gmail.com on 28 Dec 2010 at 9:21

[GoogleCodeExporter]

ok, thanks

Original comment by bg_...@mail.ru on 29 Dec 2010 at 6:44

[GoogleCodeExporter]

Can show full raw SMS from device begining with +CMGR 
(core set debug 5)

Original comment by bg_...@mail.ru on 29 Dec 2010 at 6:55

[GoogleCodeExporter]

and also enable debug logging in logger.conf

Original comment by bg_...@mail.ru on 29 Dec 2010 at 6:57

[GoogleCodeExporter]

[Dec 31 00:33:40] ERROR[1033]: at_response.c:1205 at_response_cmgr: [datacard1] 
Error decode SMS text 
'54657374206C6F6E6720736D7320626C61206468646864686468646864686468646864686468646
86468646864686468646864686468646864686468646864686468646864686468646864686468646
86468646864686468646864686468646864686468646864686468646864686468646864686468646
8646864686468646864686468646864686468646864686468736864686468646864' from 
encoding 2, message is '+CMGR: "REC 
UNREAD","002B003400340037003900350031003000300030003000300033",,"10/12/31,00:33:
38+00"
54657374206C6F6E6720736D7320626C612064686468646864686468646864686468646864686468
64686468646864686468646864686468646864686468646864686468646864686468646864686468
64686468646864686468646864686468646864686468646864686468646864686468646864686468
646864686468646864686468646864686468646864686468736864686468646864'
[Dec 31 00:33:47] ERROR[1033]: at_response.c:1205 at_response_cmgr: [datacard1] 
Error decode SMS text 
'6864656E64212120537461727465642077697468207370616365206E657720736D7320' from 
encoding 2, message is '+CMGR: "REC 
UNREAD","002B003400340037003900350031003000300030003000300033",,"10/12/31,00:33:
41+00"
6864656E64212120537461727465642077697468207370616365206E657720736D7320'

Original comment by florin.m...@gmail.com on 31 Dec 2010 at 12:34

[GoogleCodeExporter]

you use UCS-2 decode on modem not support or not activete this feature.

i say last time smsaspdu=yes

Original comment by bg_...@mail.ru on 31 Dec 2010 at 5:30

[GoogleCodeExporter]

define what smsaspdu=no

is no longer supported

Original comment by bg_...@mail.ru on 31 Dec 2010 at 5:38

[GoogleCodeExporter]

language=en                     ; set channel default language
smsaspdu=yes                     ; if 'yes' send SMS in PDU mode, feature 
implementation incomplete and we strongly recommend say 'no'
mindtmfgap=45                   ; minimal interval from end of previews DTMF 
from begining of next in ms
mindtmfduration=80              ; minimal DTMF tone duration in ms
mindtmfinterval=200             ; minimal interval between ends of DTMF of same 
digits in ms

callwaiting=no                ; if 'yes' allow incoming calls waiting; by 
default use network settings
                                ; if 'no' waiting calls just ignored
disable=no                      ; if 'yes' no load this device and just ignore 
this section

SO IS YES in my config!!!!

Original comment by florin.m...@gmail.com on 31 Dec 2010 at 9:16

[GoogleCodeExporter]

Florin,

message read format 
+CMGR: "REC UNREAD" 
is TEXT format

PDU like this
+CMGR: 0,,106
0791111111110......

please check device settings with 
datacard show device

also you may be use AT+CMGF=1 manually or use other program for this device?

Original comment by bg_...@mail.ru on 31 Dec 2010 at 12:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

datacard sms MTS2 10245 "" приводит к краху астера, а 
datacard sms MTS2 10245 '' к -- [MTS2] Error sending SMS message [Jan 5 
09:52:50] ERROR[2579]: at_response.c:490 at_response_error: [MTS2] Error 
sending SMS message Вторая проблема с смс: перестала 
работать отсылка СМС на номера, 
начинающиеся без знака плюс.

Original comment by ipetrova...@gmail.com on 5 Jan 2011 at 7:59

[GoogleCodeExporter]

datacard sms MTS2 10245 "" приводит к краху астера

fixed in r139

Original comment by bg_...@mail.ru on 5 Jan 2011 at 11:09

[GoogleCodeExporter]

you should set SC server address in modem

Original comment by bg_...@mail.ru on 5 Jan 2011 at 11:15

[GoogleCodeExporter]

check result of
CLI>  datacard show device MTS2 

line
SMS Service Center 

Original comment by bg_...@mail.ru on 5 Jan 2011 at 11:17

[GoogleCodeExporter]

Other possible reason: chan_datacard assume  number in international format, 
and assign to Type of Address value 145 (0x91), for short number this may be 
not true.

and SC, receiveing message with TOA=145, DST="10245" and can't with path to 
"10245" in international domain.

For checking this i need PDU from message, received from short number.

Original comment by bg_...@mail.ru on 5 Jan 2011 at 11:25

[GoogleCodeExporter]

rev 168:
 datacard sms datacard0 0044795XXXXXXX testing the sms
[datacard0] SMS queued for send
    -- [datacard0] Datacard has disconnected
    -- [datacard0] IMEI  IMSI 234100763XXXXXX found on data_tty /dev/ttyUSB5 audio_tty /dev/ttyUSB4
    -- [datacard0] Trying to connect on /dev/ttyUSB5...
    -- [datacard0] Datacard has connected, initializing...
    -- [datacard0] Datacard initialized and ready
But if i send 079.... works...

Original comment by florin.m...@gmail.com on 14 Jan 2011 at 12:58

[GoogleCodeExporter]

what device and firmware you use?

Original comment by bg_...@mail.ru on 14 Jan 2011 at 9:00

[GoogleCodeExporter]

first datacard0 is:
 E1550      11.608.14.15.311
since i have more then 1 device.. testing on a different hardware/firmware too:
 datacard sms datacard5 07951xxxxxx testings
[datacard5] SMS queued for send
    -- [datacard5] Datacard has disconnected
where this card is:
 E160       11.609.10.02.432
and:
datacard sms datacard6 07951xxxxxx testings
[datacard6] SMS queued for send
    -- [datacard6] Datacard has disconnected
where this card is:
 E180       11.126.04.02.18

Original comment by florin.m...@gmail.com on 14 Jan 2011 at 10:52

[GoogleCodeExporter]

I think i found the problem.
Every time is a error sending a SMS, it does a reset.
The errors i tried: invalid number format, or no credit on the sim card!

Original comment by florin.m...@gmail.com on 14 Jan 2011 at 10:57

[GoogleCodeExporter]

i stricty recomending not use  11.608.14.15.311 for E1550
please check dc-files.com for latest firmware.

modem reset or chan_datacard not got expected response ?

test case if 'try send SMS to invalid number', right?

Original comment by bg_...@mail.ru on 14 Jan 2011 at 12:27

[GoogleCodeExporter]

what firmware do you use or recommend ?

Original comment by florin.m...@gmail.com on 15 Jan 2011 at 9:18

[GoogleCodeExporter]

did you try latest from dc-files??  11.609.18.00

http://dc-files.com/files/huawei/modems/E1550/

Original comment by pag...@gmail.com on 15 Jan 2011 at 10:10

[GoogleCodeExporter]

flashed the new firmware, same issues. If no credit on sim or if number 
invalid, the chan_datacard deceide to reboot the stick :(

Also new bug found:
If the sms received is a wap push, datacard crashes that it is not recognize 
anymore by the chan_datacard. To make it back working i have to connect it to 
the mobile partner and after the sms is read by the mobile partner, i reconnect 
the dongle to the asterisk and card works no problem again.

Original comment by florin.m...@gmail.com on 28 Jan 2011 at 2:42

[GoogleCodeExporter]

look to 
http://code.google.com/p/datacard/issues/detail?id=55

Original comment by bg_...@mail.ru on 28 Jan 2011 at 4:22

[GoogleCodeExporter]

Issue 65 has been merged into this issue.

Original comment by bg_...@mail.ru on 4 Mar 2011 at 3:54