Re: smsc_at2.c PDU coding
thanks Andreas! Is that GSM AT PDU decoder in the cvs?! :)) If not, it should :) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
smsc_at2.c PDU coding
Hi list, I have some problems with an Siemens M20. So I came across the gsmlib project at http://www.pxh.de/fs/gsmlib/index.html. When sending the same payload tes to same number on same device /dev/ttyS1. Debug output of gsmlib's gsmsendsms: -- +CSMS: 1,1,1 -- -- OK -- AT+CMGS=17 -- -- 0015000B811037353312F6A803F4F21C? -- -- +CMGS: 84 -- -- OK Debug output of smsc_at2.c: AT2[m20]: -- AT+CMGS=17^M AT2[m20]: -- AT2[m20]: send command status: 1 AT2[m20]: -- 0011000C91947153332361A703F4F21C AT2[m20]: -- ^Z AT2[m20]: -- AT2[m20]: -- +CMGS: 89 AT2[m20]: -- OK can someone explain to me why the PDU string is differently?! In my mind these should be the same. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: smsc_at2.c PDU coding
On Freitag, November 8, 2002, at 02:13 Uhr, Stipe Tolj wrote: From: Stipe Tolj [EMAIL PROTECTED]> Date: Fre Nov 8, 2002 2:13:12 Uhr Europe/Zurich To: "[EMAIL PROTECTED]" [EMAIL PROTECTED]> Subject: smsc_at2.c PDU coding Hi list, I have some problems with an Siemens M20. So I came across the gsmlib project at http://www.pxh.de/fs/gsmlib/index.html. When sending the same payload "tes" to same number on same device /dev/ttyS1. Debug output of gsmlib's gsmsendsms: -- +CSMS: 1,1,1 -- -- OK --> AT+CMGS=17 -- --> 0015000B811037353312F6A803F4F21C? -- -- +CMGS: 84 -- -- OK Debug output of smsc_at2.c: AT2[m20]: --> AT+CMGS=17^M AT2[m20]: -- > AT2[m20]: send command status: 1 AT2[m20]: --> 0011000C91947153332361A703F4F21C AT2[m20]: --> ^Z AT2[m20]: -- > AT2[m20]: -- +CMGS: 89 AT2[m20]: -- OK can someone explain to me why the PDU string is differently?! I've decoded the stuff here. Here's the output: 2002-11-08 08:37:45 [0] INFO: Decoding: 15000B811037353312F6A803F4F21C 2002-11-08 08:37:45 [0] INFO: [TP_MTI:1:SMS-SUBMIT][TP_MMS:0][TP_SRR:0][TP_UDHI:0][TP_RP:0][TP_VPF:2] 2002-11-08 08:37:45 [0] INFO: SMS SUBMIT PDU 2002-11-08 08:37:45 [0] INFO: destination in pdu: [TON:0][NPI:ISDN][ADR:01735333216] 2002-11-08 08:37:45 [0] INFO: PID: 0 2002-11-08 08:37:45 [0] INFO: DCS: 0 2002-11-08 08:37:45 [0] INFO: VP is relative: 168 2002-11-08 08:37:45 [0] INFO: User Data Len: 3 2002-11-08 08:37:45 [0] INFO: TEXT: tes 2002-11-08 08:37:45 [0] INFO: tp_mr: 0 2002-11-08 08:37:45 [0] INFO: tp_udhi: 0 2002-11-08 08:37:45 [0] INFO: tp_udh: and the second one 2002-11-08 08:37:09 [0] INFO: Decoding: 11000C91947153332361A703F4F21C 2002-11-08 08:37:09 [0] INFO: octet 1: 17 2002-11-08 08:37:09 [0] INFO: [TP_MTI:1:SMS-SUBMIT][TP_MMS:1][TP_SRR:0][TP_UDHI:0][TP_RP:0][TP_VPF:2] 2002-11-08 08:37:09 [0] INFO: SMS SUBMIT PDU 2002-11-08 08:37:09 [0] INFO: destination in pdu: [TON:INT][NPI:ISDN][ADR:491735333216] 2002-11-08 08:37:09 [0] INFO: PID: 0 2002-11-08 08:37:09 [0] INFO: DCS: 0 2002-11-08 08:37:09 [0] INFO: VP is relative: 167 2002-11-08 08:37:09 [0] INFO: User Data Len: 3 2002-11-08 08:37:09 [0] INFO: TEXT: tes 2002-11-08 08:37:09 [0] INFO: tp_mr: 0 2002-11-08 08:37:09 [0] INFO: tp_udhi: 0 2002-11-08 08:37:09 [0] INFO: tp_udh: So the difference is only in the "MMS" (More Messages to be Sent) field and the type of number. In the first case its submitted as national number in the second as international. Also the validity period differ by one. both PDU's have "tes" as content. Andreas Fink Global Networks, Inc. -- Tel: +41-61-333 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
tv_sec on smsc_at2
In void at2_read_buffer tv.tv_sec = 0; tv.tv_usec = 1000; ret = select(privdata-fd + 1, read_fd, NULL, NULL, tv); If I disconnect modem from serial the above select does not return anything,at leastin the 2 hours I waited :-) So I'm wondering if anybody knows ifwe should changetv.tv_usec to something else than 1000 (seconds, minutes or what is this usec?) Thanks Andrea
RE: tv_sec on smsc_at2
usec is microseconds. select will wait for 1/1000of a second and if it timed out (and got back-1 and an EAGAIN errno) it will return w/o doing anything.read the select man page. if you are sure that read_buffer() does not return then I guess there is something seriously wrong with your glibc implementation. what are you running this on ? --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::..The most exciting phrase to hear in science, the one that heralds new discoveries,is not "Eureka!" but "hm... that's funny..."-- Isaac Asimov -Original Message-From: Andrea Viscovich [mailto:[EMAIL PROTECTED]]Sent: Thursday, October 24, 2002 3:21 PMTo: [EMAIL PROTECTED]Subject: tv_sec on smsc_at2 In void at2_read_buffer tv.tv_sec = 0; tv.tv_usec = 1000; ret = select(privdata-fd + 1, read_fd, NULL, NULL, tv); If I disconnect modem from serial the above select does not return anything,at leastin the 2 hours I waited :-) So I'm wondering if anybody knows ifwe should changetv.tv_usec to something else than 1000 (seconds, minutes or what is this usec?) Thanks Andrea
[BUG] smsc_at2.c: sending a one character message via Siemens M20 fails
Hi there, when you connect to a M20 via the AT2 driver and try to send a one character message the whole things fails like this: 2002-05-15 09:23:25 [19] DEBUG: boxc_receiver: sms received 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: international starting with + (+49snip) 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: TP-Validity-Period: 24.0 hours 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- AT+CMGS=15^M 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 0011000C91947153332361A70178 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- ^Z 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- +CMS ERROR: 304 2002-05-15 09:23:26 [6] ERROR: AT2[m20]: CMS ERROR: +CMS ERROR: 304 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- AT+CMGS=15^M 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 0011000C91947153332361A70178 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- ^Z 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- +CMS ERROR: 304 2002-05-15 09:23:26 [6] ERROR: AT2[m20]: CMS ERROR: +CMS ERROR: 304 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- AT+CMGS=15^M 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 0011000C91947153332361A70178 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- ^Z 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- +CMS ERROR: 304 2002-05-15 09:23:26 [6] ERROR: AT2[m20]: CMS ERROR: +CMS ERROR: 304 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 Bruno, Oded, you guys seems to deal with at2 mostly. Any ideas? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: [BUG] smsc_at2.c: sending a one character message via Siemens M20 fails
I don't know why - but the size of the message reported it not correct : kannel said to the modem it will send a PDU 15 bytes long and then sent a 16 bytes long PDU. I'll go brush up on my PDU reading skills and get back to you on this. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. 'First things first -- but not necessarily in that order' -- Dr Who -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 11:34 AM To: [EMAIL PROTECTED] Subject: [BUG] smsc_at2.c: sending a one character message via Siemens M20 fails Hi there, when you connect to a M20 via the AT2 driver and try to send a one character message the whole things fails like this: 2002-05-15 09:23:25 [19] DEBUG: boxc_receiver: sms received 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: international starting with + (+49snip) 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: TP-Validity-Period: 24.0 hours 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- AT+CMGS=15^M 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 0011000C91947153332361A70178 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- ^Z 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- +CMS ERROR: 304 2002-05-15 09:23:26 [6] ERROR: AT2[m20]: CMS ERROR: +CMS ERROR: 304 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- AT+CMGS=15^M 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 0011000C91947153332361A70178 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- ^Z 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- +CMS ERROR: 304 2002-05-15 09:23:26 [6] ERROR: AT2[m20]: CMS ERROR: +CMS ERROR: 304 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- AT+CMGS=15^M 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 0011000C91947153332361A70178 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- ^Z 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: -- +CMS ERROR: 304 2002-05-15 09:23:26 [6] ERROR: AT2[m20]: CMS ERROR: +CMS ERROR: 304 2002-05-15 09:23:26 [6] DEBUG: AT2[m20]: send command status: 1 Bruno, Oded, you guys seems to deal with at2 mostly. Any ideas? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Snapshots aren't being built (Was: Re: smsc_at2.c at+cmms=2)
On Fri, 2002-04-19 at 11:26, David Holland wrote: On Thu, Apr 18, 2002 at 04:21:08PM +0100, Bruno Rodrigues wrote: something must gone wrong... snapshot-timestamp says Apr 09, snapshot doesn't have my patch and I've commited it on Apr 10 OK. There was a missing /row in userguide.xml. I checked in a fix and poked the snapshot script. (Don't you guys try to build the docs before checking them in?!?!) Shouldn't the scripts detect the error and send us an email to devel-reports ? ;) Cheers, Dave -- David Holland =*= Systems Manager =*= tel: +44 01223 478900 http://www.3glab.com/ =*= 3G Lab, UK =*= fax: +44 01223 478901 I had problems with a ferrous one that I couldn't iron out.
Re: Snapshots aren't being built (Was: Re: smsc_at2.c at+cmms=2)
On Fri, Apr 19, 2002 at 05:14:44PM +0100, Bruno David Simões Rodrigues wrote: Shouldn't the scripts detect the error and send us an email to devel-reports ? ;) Yes :-( Dave -- David Holland =*= Systems Manager =*= tel: +44 01223 478900 http://www.3glab.com/ =*= 3G Lab, UK =*= fax: +44 01223 478901 Ogden's Law: The sooner you fall behind, the more time you have to catch up.
smsc_at2.c at+cmms=2
Inside the code there is a call to at+cmms=2 if(list_len(privdata-outgoing_queue) 1) at2_send_modem_command(privdata, AT+CMMS=2, 0, 0); On all wavecom this generates an error response. Looking to at manual (wavecom) there is no mention to this. Does anybody know anything about it? Andrea Viscovich Email2Mobile: [EMAIL PROTECTED] Web: http://www.smsprof.it
RE: smsc_at2.c at+cmms=2
I don't know what is +CMMS (IIRC it isn't mentioned on the wavecom manual), what its suposed to do or why Bruno put it in, but latest CVS has a configuration for that (in modems.conf) that is disabled by default for most modem types (only enabled for nokia phone in the sample modems.conf). -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. I heard someone tried the monkeys-on-typewriters bit trying for the plays of W. Shakespeare, but all they got was the collected works of Francis Bacon. -- Bill Hirst -Original Message- From: Andrea Viscovich [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 1:01 PM To: [EMAIL PROTECTED] Subject: smsc_at2.c at+cmms=2 Inside the code there is a call to at+cmms=2 if(list_len(privdata-outgoing_queue) 1) at2_send_modem_command(privdata, AT+CMMS=2, 0, 0); On all wavecom this generates an error response. Looking to at manual (wavecom) there is no mention to this. Does anybody know anything about it? Andrea Viscovich Email2Mobile: [EMAIL PROTECTED] Web: http://www.smsprof.it
RE: smsc_at2.c at+cmms=2
+CMMS is More messages to send and is used by the Siemens, however not by most other devices. Have a look at http://gatling.ikk.sztaki.hu/~kissg/gsm/at+c.html and reports from Siemens vs. Falcon there too. Alex On Thu, 18 Apr 2002, Oded Arbel wrote: I don't know what is +CMMS (IIRC it isn't mentioned on the wavecom manual), what its suposed to do or why Bruno put it in, but latest CVS has a configuration for that (in modems.conf) that is disabled by default for most modem types (only enabled for nokia phone in the sample modems.conf). -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. I heard someone tried the monkeys-on-typewriters bit trying for the plays of W. Shakespeare, but all they got was the collected works of Francis Bacon. -- Bill Hirst -Original Message- From: Andrea Viscovich [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 1:01 PM To: [EMAIL PROTECTED] Subject: smsc_at2.c at+cmms=2 Inside the code there is a call to at+cmms=2 if(list_len(privdata-outgoing_queue) 1) at2_send_modem_command(privdata, AT+CMMS=2, 0, 0); On all wavecom this generates an error response. Looking to at manual (wavecom) there is no mention to this. Does anybody know anything about it? Andrea Viscovich Email2Mobile: [EMAIL PROTECTED] Web: http://www.smsprof.it -- Alex Judd http://www.skywire.co.uk
RE: smsc_at2.c at+cmms=2
On Thu, 2002-04-18 at 12:57, Alex Judd wrote: +CMMS is More messages to send and is used by the Siemens, however not by most other devices. Uhm. I've set it disabled by default because altough it works with nokia 6210, it ain't working with Siemens M20...
Re: smsc_at2.c at+cmms=2
Thanks Alex and Oded.
but latest CVS
has a configuration for that (in modems.conf) that is disabled by
default for most modem types
I just dowloaded latest tar.gz (snapshot). There is exactly the same code:
void at2_send_messages(PrivAT2data *privdata)
{
Msg *msg;
do
{
if(list_len(privdata-outgoing_queue) 1)
at2_send_modem_command(privdata, AT+CMMS=2, 0, 0);
if( ( msg = list_extract_first(privdata-outgoing_queue )))
at2_send_one_message(privdata, msg);
} while (msg);
}
I think I'll cut the at2_send_modem_command away.
Andrea
Snapshots aren't being built (Was: Re: smsc_at2.c at+cmms=2)
- Original Message - From: Andrea Viscovich [EMAIL PROTECTED] To: Alex Judd [EMAIL PROTECTED]; Oded Arbel [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, April 18, 2002 3:51 PM Subject: Re: smsc_at2.c at+cmms=2 Thanks Alex and Oded. but latest CVS has a configuration for that (in modems.conf) that is disabled by default for most modem types I just dowloaded latest tar.gz (snapshot). There is exactly the same code: http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc_at2.c?annota te=1.44#1425 Snapshots aren't beeing built since Apr 09, and I've commited in Apr 10. Please try the cvs version for now
Re: Snapshots aren't being built (Was: Re: smsc_at2.c at+cmms=2)
Subject: Snapshots aren't being built (Was: Re: smsc_at2.c at+cmms=2) Hi Bruno, can you tell me why this happens? Still I tought snapshot were built at 4.00 every morning. Is there any reason as someone stopeed it? Cheers Andrea
Rif: RE: speed (smsc_at2.c)
I think that at2 should autodetect speed if it doesn't find any speed setting, in the smsc group or modems.conf, or if the smsc speed setting is set to 0 regardless of the modems.conf setting, or the modems.conf setting is set to 0 - isn't that the case now ? No. Now you must set speed=0 if you want speed to be autodetected, otherwise it behaves as you set speed = 9600. That's why I think if no speed is specified than it should be autodetect. Andrea
Re: speed (smsc_at2.c)
Bruno David Rodrigues wrote: If we choose the modem, should kannel autodetect the speed or try to autodetect? Andrea wants to kannel always autodetect speed unless it's explicity set in smsc group I chosed to have a known working speed in modems.conf and use it, and only force autodetect if we want. I'm ok with both solutions. What do the others think about it ? what about dascading, like this: a) test the fixed known speed from modem.conf b) if it fails, which should not, try to autodetect Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Rif: RE: speed (smsc_at2.c)
[EMAIL PROTECTED] wrote: I think that at2 should autodetect speed if it doesn't find any speed setting, in the smsc group or modems.conf, or if the smsc speed setting is set to 0 regardless of the modems.conf setting, or the modems.conf setting is set to 0 - isn't that the case now ? No. Now you must set speed=0 if you want speed to be autodetected, otherwise it behaves as you set speed = 9600. That's why I think if no speed is specified than it should be autodetect. +1 from me. If no 'speed' directive is specified in the group, autodetect should be used, because you don't have a garantee that a 9600 speeded device is attached to the port. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Rif: RE: speed (smsc_at2.c)
But that's why there is a speed in modems.conf. That's why Siemens M20 have a 19200, because *every* works at 19200 and not at 9600. But the problem is that *every*. There's equal modems at one speed and others at other speed (wavecom). That's why there is a speed in smsc group, to force a speed different from the speed defined in modems.conf. I'm commiting a patch to change this behaviour. If smsc-speed is defined, use it. Else try to use modem-speed (if defined, of course). If this one fails, try to autodetect Is it ok ? - Original Message - From: Stipe Tolj [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Oded Arbel [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 27, 2002 10:18 AM Subject: Re: Rif: RE: speed (smsc_at2.c) [EMAIL PROTECTED] wrote: I think that at2 should autodetect speed if it doesn't find any speed setting, in the smsc group or modems.conf, or if the smsc speed setting is set to 0 regardless of the modems.conf setting, or the modems.conf setting is set to 0 - isn't that the case now ? No. Now you must set speed=0 if you want speed to be autodetected, otherwise it behaves as you set speed = 9600. That's why I think if no speed is specified than it should be autodetect. +1 from me. If no 'speed' directive is specified in the group, autodetect should be used, because you don't have a garantee that a 9600 speeded device is attached to the port. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Rif: RE: speed (smsc_at2.c)
+1 for me :-) Andrea - Original Message - From: Bruno David Rodrigues [EMAIL PROTECTED] To: Stipe Tolj [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Oded Arbel [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 27, 2002 4:20 PM Subject: Re: Rif: RE: speed (smsc_at2.c) But that's why there is a speed in modems.conf. That's why Siemens M20 have a 19200, because *every* works at 19200 and not at 9600. But the problem is that *every*. There's equal modems at one speed and others at other speed (wavecom). That's why there is a speed in smsc group, to force a speed different from the speed defined in modems.conf. I'm commiting a patch to change this behaviour. If smsc-speed is defined, use it. Else try to use modem-speed (if defined, of course). If this one fails, try to autodetect Is it ok ? - Original Message - From: Stipe Tolj [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Oded Arbel [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 27, 2002 10:18 AM Subject: Re: Rif: RE: speed (smsc_at2.c) [EMAIL PROTECTED] wrote: I think that at2 should autodetect speed if it doesn't find any speed setting, in the smsc group or modems.conf, or if the smsc speed setting is set to 0 regardless of the modems.conf setting, or the modems.conf setting is set to 0 - isn't that the case now ? No. Now you must set speed=0 if you want speed to be autodetected, otherwise it behaves as you set speed = 9600. That's why I think if no speed is specified than it should be autodetect. +1 from me. If no 'speed' directive is specified in the group, autodetect should be used, because you don't have a garantee that a 9600 speeded device is attached to the port. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
speed (smsc_at2.c)
Well, I noticed an error is caused by the different speed. As noticed by someone else there should be some problems autodetecting speed. As Bruno said speed should be autodetected if not specified, by the way is not so now (but it was). I have 6 modem wavecom 5 modem has 9600, one has 19200. With current cvs, it sets speed to 9600 (I don't set it in kannel.conf) and then 5 modem works, the 19200 gets "no answer from modem". This is an error that should be fixed before new release. Andrea Andrea Viscovich Direct Line: +39 041 2574825 email :[EMAIL PROTECTED]
Re: speed (smsc_at2.c)
I could be more explicit in documentation... If you have modemtype = auto in smsc, kannel would autodetect speed and modem. If you set the modemtype, kannel will use the group from modems.conf, and if speed is unset in it, kannel uses 9600. If you explicitly want kannel to autodetect, use speed = 0 in smsc group. The idea was that if someone knows that a certain modem works at a certain speed, it should be defined in modems.conf and kannel won't need to autodetect. if one specific modem don't work at that speed, just set it at smsc group or set it to 0 to autodetect. - Original Message - From: Andrea Viscovich To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 3:44 PM Subject: speed (smsc_at2.c) Well, I noticed an error is caused by the different speed. As noticed by someone else there should be some problems autodetecting speed. As Bruno said speed should be autodetected if not specified, by the way is not so now (but it was). I have 6 modem wavecom 5 modem has 9600, one has 19200. With current cvs, it sets speed to 9600 (I don't set it in kannel.conf) and then 5 modem works, the 19200 gets "no answer from modem". This is an error that should be fixed before new release. Andrea Andrea Viscovich Direct Line: +39 041 2574825 email :[EMAIL PROTECTED]
Re: speed (smsc_at2.c)
If you set the modemtype, kannel will use the group from modems.conf, and if speed is unset in it, kannel uses 9600. If you explicitly want kannel to autodetect, use speed = 0 in smsc group. I would have preferred to not set speed=0 to have it autodetect. Now that I know it, I'll do it. Actually I solved it just creating 2 modem groups setting the 2 different speed. Thanks Andrea
Re: speed (smsc_at2.c)
Just set the speed on the smscgroup you want - Original Message - From: Andrea Viscovich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 4:27 PM Subject: Re: speed (smsc_at2.c) If you set the modemtype, kannel will use the group from modems.conf, and if speed is unset in it, kannel uses 9600. If you explicitly want kannel to autodetect, use speed = 0 in smsc group. I would have preferred to not set speed=0 to have it autodetect. Now that I know it, I'll do it. Actually I solved it just creating 2 modem groups setting the 2 different speed. Thanks Andrea
RE: smsc_at2
+CMTI: SM, AFAIR, means that the message landed in SM memory (SIM card - '3' probably means you'll find it in memory location 3, the first two obviously already filled). we should do two things - (a) teach kannel to look for +CMT: and not any +CMT like it does now, and (b) apply the SIM buffering patch so it will read the messages from the SIM card. Why does it do so with alphanumeric sender ? I guess it's modem dependant and nothing Kannel can do about. Cheers Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Q: How many Microsoft engineers does it take to change a light bulb? A: None. Bill Gates will just redefine Darkness(TM) as the new industry standard. -Original Message- From: Andrea Viscovich [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 26, 2002 9:49 AM To: [EMAIL PROTECTED] Subject: smsc_at2 Today I sent to my wavecom gsm modem (at2 current cvs) a sms with alphanumeric sender. Instead of the usual +CMT:, 25 (or whatever number) and the pdu, I got: +CMTI: SM,3 nothing else. Obviusly kannel said I got CMT but wait next line timed out. I think we should do something in at2 before new release. Sending same sms on my 8210 works, id est it reads correctly it. Andreas? Regards Andrea
Rif: RE: smsc_at2
we should do two things - (a) teach kannel to look for +CMT: and not any +CMT and (b) apply the SIM buffering patch Why does it do so with alphanumeric sender ? I guess it's modem dependant and nothing Kannel can do about. Hi there, I totally agree with you, we have to change to +CMT:, and who is gonna apply the sim buffering patch? Andrea
smsc_at2
Today I sent to my wavecom gsm modem (at2 current cvs) a sms with alphanumeric sender. Instead of the usual +CMT:, 25 (or whatever number) and the pdu, I got: +CMTI: SM,3 nothing else. Obviusly kannel said I got CMT but wait next line timed out. I think we should do something in at2 before new release. Sending same sms on my 8210 works, id est it reads correctly it. Andreas? Regards Andrea
Re: [PATCH] nailed another smsc_at2.c memory leak.
patch applied, thanks! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
[PATCH] nailed another smsc_at2.c memory leak.
Patch attached. pretty straight forward. hope I've seen the last of 'em :-) TIA Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- I learned that it is the weak who are cruel, and that gentleness is to be expected only from the strong. --Leo Rosten smsc_at2.patch smsc_at2.patch Description: smsc_at2.patch
Re: [PATCH] nailed another smsc_at2.c memory leak.
Oded Arbel wrote: Patch attached. pretty straight forward. hope I've seen the last of 'em :-) any objections from your side Andreas? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: I minor error found in gw/smsc_at2.c
Nektarios K. Papadopoulos wrote: I am using smsc_at with a NOKIA Premicell. Thoughth to give a try on smsc_at2. What I was getting was something like: 2002-02-20 01:20:24 [6] DEBUG: AT2[/dev/ttyS1]: -- +CSMS: (0) 2002-02-20 01:20:24 [6] DEBUG: AT2[/dev/ttyS1]: -- OK 2002-02-20 01:20:24 [6] INFO: AT2[/dev/ttyS1]: Phase 2+ is supported 2002-02-20 01:20:24 [6] DEBUG: AT2[/dev/ttyS1]: -- AT+CSMS=1^M 2002-02-20 01:20:24 [6] DEBUG: AT2[/dev/ttyS1]: -- ERROR I looke my AT command reference and the code and think that I should not get Phase 2+ is supported I think that passing octstr_case_compare to list_search, makes it to search for at least one non matching list element, insteat for one matching. So I suggest changing it to octstr_item_match, since we care only for digits. the diff with todays cvs is attached, in case I am not wrong. any votes from the others, please?! Putting this at least to STATUS for now. yes this is a bug. +CSMS(0) should return Phase 2+ is not supported. the nokia premicel is probably the only device left on this planet which doesnt support phase 2+. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: I minor error found in gw/smsc_at2.c
yes this is a bug. +CSMS(0) should return Phase 2+ is not supported. the nokia premicel is probably the only device left on this planet which doesnt support phase 2+. Hi Andreas. No. I'm plenty of devices who doesn't support it. Even a wavecom dual band and a 7110. Well my 7110 and my wavecom both support 2+. So you might have old firmware. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Lucio Ferrao wrote:
When smsc_at2 sent a message in 7bit the length written in the PDU did not
include
the escape chars. I solved the problem calling the charset_latin1_to_gsm a
little earlier.
This lead to missing end chars when using escaped chars []...
Lucio Ferrao
OutSystems
Index: gw/smsc_at2.c
===
RCS file: /home/cvs/gateway/gw/smsc_at2.c,v
retrieving revision 1.18
diff -c -r1.18 smsc_at2.c
*** gw/smsc_at2.c 2002/01/09 08:31:41 1.18
--- gw/smsc_at2.c 2002/01/23 19:24:19
***
*** 1490,1495
--- 1490,1498
pos++;
/* user data length - include length of UDH if it exists*/
+ if (msg-sms.coding == DC_7BIT) {
+ charset_latin1_to_gsm(msg-sms.msgdata);
+ }
len = octstr_len(msg-sms.msgdata);
if(octstr_len(msg-sms.udhdata)) {
***
*** 1551,1557
int ermask[8] = { 0, 1, 3, 7, 15, 31, 63, 127 };
int elmask[8] = { 0, 64, 96, 112, 120, 124, 126, 127 };
- charset_latin1_to_gsm(input);
len = octstr_len(input);
/* prevoctet is set to the first character and we'll start the loop
--- 1554,1559
is the patch from Oded Arbel [EMAIL PROTECTED] I just applied, see
http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/ChangeLog?rev=1.1665content-type=text/vnd.viewcvs-markup
solving this problem?
Can you please checkout a fresh cvs tree and try if this fixes the
behaviour you noticed?
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Münsterstr. 248
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
RE: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Last week I've submitted two patches to the list (Message-ID: [EMAIL PROTECTED] and Message-ID: [EMAIL PROTECTED]) concerning with this issue. the former is exactly as described below, but I did not think it solves the wider issue, hence the second patch - which I would like to hear the developer's opinion on, as I think it solves the encoding problem on a lower level so other modules, besides at2, can benefit from it. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- I'm a Software De-engineer. You write software? No, I crash it. -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 10:06 PM Cc: Devel@Kannel. 3glab. Org Subject: Re: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit) Lucio Ferrao wrote: When smsc_at2 sent a message in 7bit the length written in the PDU did not include the escape chars. I solved the problem calling the charset_latin1_to_gsm a little earlier. This lead to missing end chars when using escaped chars []... Thanks a lot Lucio for the patch. Any votes for commiting this to cvs please?! I'm +0 due to imperfect knowledge about it ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Hi List, I'm thinking about a general overhaul in this area. The interaction of * 7bit escape characters * UDH with multiple IEI's * message splitting and concatenation is a big mess right now (IMHO). What I would suggest is to discourage the use of the generic udh parameter (X-Kannel-UDH) and replace it with an iei parameter. This way Kannel could collect all IEI's in a message and easily distribute them over multiple separate SM's and prepend the correct concatenation header. I think this is needed for a fully working EMS implementation. Regards Jörg -Original Message- From: Stipe Tolj Cc: Devel@Kannel. 3glab. Org Sent: 1/23/02 9:06 PM Subject: Re: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit) Lucio Ferrao wrote: When smsc_at2 sent a message in 7bit the length written in the PDU did not include the escape chars. I solved the problem calling the charset_latin1_to_gsm a little earlier. This lead to missing end chars when using escaped chars []... Thanks a lot Lucio for the patch. Any votes for commiting this to cvs please?! I'm +0 due to imperfect knowledge about it ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Hi List, I'm thinking about a general overhaul in this area. The interaction of * 7bit escape characters * UDH with multiple IEI's * message splitting and concatenation is a big mess right now (IMHO). I agree to some extent. Things are done in different places or even done twice. We have to rethink this a bit. What I would suggest is to discourage the use of the generic udh parameter (X-Kannel-UDH) and replace it with an iei parameter. This way Kannel could collect all IEI's in a message and easily distribute them over multiple separate SM's and prepend the correct concatenation header. I think this is needed for a fully working EMS implementation. Hmm. I wouldnt go that far. udh is correct so far. For EMS, I think the only way is to do the splitting on the application. The IEI's are related to the text message they are pointing to so having a large IEI and a large text would just mean we create another new format. If we should do a better conversion, then we should do it full blown (I'm not saying kannel should go this far) conversion from existing standards like HTML with GIF images to EMS or something like that. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
FW: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Hi list. Since we're already discussing the at2 gsm7bit escaping issue, I would like to resubmit my suggested fix for the problem (as apparently it did not arrive to the proper authorities the first time). my apologies if you are reading it for the second time. I would like to hear any comments on the patch, especially if it is rejected. TIA Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Joe: Billy prefers models and limousines. I can do with hookers and taxis. -- from Hard Core Logo -Original Message- From: Alex Judd [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 1:56 PM To: Oded Arbel Subject: RE: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit) Looks sensible. Check your at2_wait_mdoem_command which you're calling with 4 parameters in the patch however I think adding your changes to cvs makes sense. Alex On Thu, 24 Jan 2002, Oded Arbel wrote: my first patch (as is Lucio Ferrao's) is to encode to gsm before the length calculation. Attached is my email containing the second patch. ---BeginMessage--- Hi list. sorry about that last post - thinking about it, it doesn't seem to me like the right solution : yea, it works, but it doesn't address the wider issue which Andreas Fink mentioned. So, for your inspection, I submit this larger patch, which I hope solves the particular problem Andreas Fink talked about, and as a side effect, helps me with a cleaner solution to the problem with AT2. this patch is against current CVS, and it's a bit large - so I'll try to explain : to sms.c/.h I added a function called sms_msgdata_len() to which you can pass a Msg struct and get the number of actual septets or octets this message will contain after encoding (based on the message's coding). I then changed smsc_at2.c to use that function to intialize len in at2_pdu_encode() to the right value, no matter what encoding the msg will be delivered. then to the real problem at hand : to shared.c I added the function extract_msgdata_part_by_coding() which is a wapper for extract_msgdata_part() that will make sure that if the message is 7 bit coded and contains 'escaped' characters, it will cut the message to the right size. I then proceeded to change sms_split() to use the two new functions. I hope this will help, and have a nice day :-) Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Trifles make perfection, and perfection is no trifle. -- Michelangelo -Original Message- From: Oded Arbel Sent: Tuesday, January 15, 2002 12:29 PM To: Andreas Fink Cc: [EMAIL PROTECTED] Subject: RE: A question about PDU encoding in smsc_at2 Thank you all for the responses.. I couldn't find where messages get split in smsc_at2 , from my tests it appears that messages get truncated and not split - but I can't figure out where that happens. anyway - this small patch will convert to gsm 7 bit alphabet early, before the length computations, and does solve the escape sequences problem for me. the usual warnings - Works For Me(tm), YMMV, etc'. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Some say life is hell and death an escape, others say heaven awaits us in the world beyond, but either way I need a new pair of shoes. -- Privateer. -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 6:38 PM To: Oded Arbel Cc: [EMAIL PROTECTED] Subject: RE: A question about PDU encoding in smsc_at2 This is not exactly what I had in mind - (a) as this kind of string would get translated by kannel to '?' as ESC will be translated directly to '?'. (b) the GSM standards _currently_ do define the ESC sequences as valid. I'm not really worried about current standard support in phone (as newer phones would surely conform to the current standards), but more with standard support within Kannel. and my question is (again) - which do you think is the correct implementation, Kannel's counting only actual characters, or Siemens M20's counting every septet ? P.S tests show that some phones just silently ignore the escape sequences (showing the character after the ESC - the triangle bracket), for example - the Nokia 33, and some show the intended result - the square bracket, for example - the Nokia 71. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] What I can tell from EMI usage, the escape sequence stuff is slightly broken. I got customers sending \n in their text (because they've forgotton to replace it with linefeed). In kannel this translates the \ to two characters. The problem here is that it increses the size of the text and this AFTER the message has been split. The result of that is that we will end up with SMS being longer than 160 characters. So while you take a look into this, think about this fact. The final header has to be the number of octets of the SMS after escape sequences have been applied. The escape stuff is something done in the phone and the SMSC never cares about it. For the SMSC its just a stream of bytes
Re: FW: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
The changes make sense to me including a minor fix for error handling and the major flow changes are well commented so if someone can test in a live environment I would vote for commiting. Alex On Thu, 24 Jan 2002, Oded Arbel wrote: Hi list. Since we're already discussing the at2 gsm7bit escaping issue, I would like to resubmit my suggested fix for the problem (as apparently it did not arrive to the proper authorities the first time). my apologies if you are reading it for the second time. I would like to hear any comments on the patch, especially if it is rejected.
Re: FW: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Oded Arbel wrote: Hi list. Since we're already discussing the at2 gsm7bit escaping issue, I would like to resubmit my suggested fix for the problem (as apparently it did not arrive to the proper authorities the first time). my apologies if you are reading it for the second time. I would like to hear any comments on the patch, especially if it is rejected. I had a look on this and I'm giving a +1 for commitment. Others please?! Just applied the patch to a test environment and giving it a try for various smsc types. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: FW: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Stipe Tolj wrote: Just applied the patch to a test environment and giving it a try for various smsc types. tested messages via EMI2, SMPP and AT2, all ok. +1 for commitment from my side. Can someone test against the issues the patch is fixing, I guess I only tried to send normal messages through it? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: A question about PDU encoding in smsc_at2
Hi list. sorry about that last post - thinking about it, it doesn't seem to me like the right solution : yea, it works, but it doesn't address the wider issue which Andreas Fink mentioned. So, for your inspection, I submit this larger patch, which I hope solves the particular problem Andreas Fink talked about, and as a side effect, helps me with a cleaner solution to the problem with AT2. this patch is against current CVS, and it's a bit large - so I'll try to explain : to sms.c/.h I added a function called sms_msgdata_len() to which you can pass a Msg struct and get the number of actual septets or octets this message will contain after encoding (based on the message's coding). I then changed smsc_at2.c to use that function to intialize len in at2_pdu_encode() to the right value, no matter what encoding the msg will be delivered. then to the real problem at hand : to shared.c I added the function extract_msgdata_part_by_coding() which is a wapper for extract_msgdata_part() that will make sure that if the message is 7 bit coded and contains 'escaped' characters, it will cut the message to the right size. I then proceeded to change sms_split() to use the two new functions. I hope this will help, and have a nice day :-) Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Trifles make perfection, and perfection is no trifle. -- Michelangelo -Original Message- From: Oded Arbel Sent: Tuesday, January 15, 2002 12:29 PM To: Andreas Fink Cc: [EMAIL PROTECTED] Subject: RE: A question about PDU encoding in smsc_at2 Thank you all for the responses.. I couldn't find where messages get split in smsc_at2 , from my tests it appears that messages get truncated and not split - but I can't figure out where that happens. anyway - this small patch will convert to gsm 7 bit alphabet early, before the length computations, and does solve the escape sequences problem for me. the usual warnings - Works For Me(tm), YMMV, etc'. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Some say life is hell and death an escape, others say heaven awaits us in the world beyond, but either way I need a new pair of shoes. -- Privateer. -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 6:38 PM To: Oded Arbel Cc: [EMAIL PROTECTED] Subject: RE: A question about PDU encoding in smsc_at2 This is not exactly what I had in mind - (a) as this kind of string would get translated by kannel to '?' as ESC will be translated directly to '?'. (b) the GSM standards _currently_ do define the ESC sequences as valid. I'm not really worried about current standard support in phone (as newer phones would surely conform to the current standards), but more with standard support within Kannel. and my question is (again) - which do you think is the correct implementation, Kannel's counting only actual characters, or Siemens M20's counting every septet ? P.S tests show that some phones just silently ignore the escape sequences (showing the character after the ESC - the triangle bracket), for example - the Nokia 33, and some show the intended result - the square bracket, for example - the Nokia 71. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] What I can tell from EMI usage, the escape sequence stuff is slightly broken. I got customers sending \n in their text (because they've forgotton to replace it with linefeed). In kannel this translates the \ to two characters. The problem here is that it increses the size of the text and this AFTER the message has been split. The result of that is that we will end up with SMS being longer than 160 characters. So while you take a look into this, think about this fact. The final header has to be the number of octets of the SMS after escape sequences have been applied. The escape stuff is something done in the phone and the SMSC never cares about it. For the SMSC its just a stream of bytes. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink gw.patch Description: gw.patch
RE: A question about PDU encoding in smsc_at2
Ok, this is where I have some problems : looking just at at2_pdu_encode(), I think the UDH never gets converted to 7 bit chars, but always remains as 8 bit chars. another question that is probably not related : on my Siemens M20, whenever I send a SM (using at2) which contains characters which should be 'escaped' acording to the GSM charset (for example - the square brackets which I like to use), the modem rejects the message with error 304 invalid PDU mode parameter. I found out that if I encode the message length byte (UDL) in the PDU to cound 'escaped' characters as 2 chars (one for the char and one for the ESC), the modem accepts the message. Does that sounds reasonable ? do other modems count escaped chars as one char ? is it a bug in the modem ? From the GSM documentation I could understand that the UDL should count GSM 7 bit characters, but from the siemens documentation I got two quote - from the 'Developer's Guide : SMS with the SMS PDU-mode' : The UDL field gives an integer representation of the number of characters within the User Data field to follow but from the M20 manual (in german) : UDL (user DATA length) value must agree exact with the byte length of the string. When I recieve a message, the UDL field indicates the number of septets (counting ESC as a char) in the message. Do you think that the M20 doesn't follow the GSM standard here ? Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- What's in it doesn't count - it's the presntation that matters. -- Fishizm -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 9:19 AM To: Oded Arbel Subject: RE: A question about PDU encoding in smsc_at2 oh - I get it : the UDH is already encoded correctly using the right DCS before the call to at2_pdu_encode(), and then at2_pdu_encode() only needs to translate the bitstream to hex strings, and in the length computation it computes how many septets are in the already encoded bit stream - right ? Im not sure if thats the case. However at the end, the UDH must contain the number of final octets. so at2_pdu_encode will most probably call the 7 to 8 bit conversion but calculate the length for the udh before that. The routine was copied out of previous at driver without any changes (meaning it always worked but I didnt write it). -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: A question about PDU encoding in smsc_at2
(for example - the square brackets which I like to use), the modem rejects the message with error 304 invalid PDU mode parameter. Well, this will probably hurt you, but I'm afraid square brackets are not part of GSM character set. At least I didn't see them there.
RE: A question about PDU encoding in smsc_at2
-Original Message- From: Alexei Pashkovsky [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:09 PM To: Oded Arbel Cc: Kannel-devel (E-mail) Subject: Re: A question about PDU encoding in smsc_at2 (for example - the square brackets which I like to use), the modem rejects the message with error 304 invalid PDU mode parameter. Well, this will probably hurt you, but I'm afraid square brackets are not part of GSM character set. At least I didn't see them there. I'm sorry too, but square brackets are part of the GSM 03.38 alphabet, according to this : http://www.dreamfabric.com/sms/default_alphabet.html or you can get the official document from http://pda.etsi.org/pda/home.asp?wki_id=6821 Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- This is my SIG. There are many like it, but this one is mine.
Re: A question about PDU encoding in smsc_at2
Alexei Pashkovsky wrote: (for example - the square brackets which I like to use), the modem rejects the message with error 304 invalid PDU mode parameter. Well, this will probably hurt you, but I'm afraid square brackets are not part of GSM character set. At least I didn't see them there. There *is* a way, however. IIRC the sequence ESC- or ESC- will work, ie: %1b%3c and %1b%3e See a recent revision of GSM 3.38 for the gory details of this and a few other escape sequences, including the Euro sign (%1b%65). Keep in mind that this will look pretty stupid on many handsets, including relatively advanced models like the Motorola Accompli 008. David WHITE CONNECT AUSTRIA
RE: A question about PDU encoding in smsc_at2
This is not exactly what I had in mind - (a) as this kind of string would get translated by kannel to '?' as ESC will be translated directly to '?'. (b) the GSM standards _currently_ do define the ESC sequences as valid. I'm not really worried about current standard support in phone (as newer phones would surely conform to the current standards), but more with standard support within Kannel. and my question is (again) - which do you think is the correct implementation, Kannel's counting only actual characters, or Siemens M20's counting every septet ? P.S tests show that some phones just silently ignore the escape sequences (showing the character after the ESC - the triangle bracket), for example - the Nokia 33, and some show the intended result - the square bracket, for example - the Nokia 71. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- As long as you do not move you can still choose any direction. -Original Message- From: Dave White [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:26 PM To: Kannel-devel (E-mail) Subject: Re: A question about PDU encoding in smsc_at2 Alexei Pashkovsky wrote: (for example - the square brackets which I like to use), the modem rejects the message with error 304 invalid PDU mode parameter. Well, this will probably hurt you, but I'm afraid square brackets are not part of GSM character set. At least I didn't see them there. There *is* a way, however. IIRC the sequence ESC- or ESC- will work, ie: %1b%3c and %1b%3e See a recent revision of GSM 3.38 for the gory details of this and a few other escape sequences, including the Euro sign (%1b%65). Keep in mind that this will look pretty stupid on many handsets, including relatively advanced models like the Motorola Accompli 008. David WHITE CONNECT AUSTRIA
RE: A question about PDU encoding in smsc_at2
This is not exactly what I had in mind - (a) as this kind of string would get translated by kannel to '?' as ESC will be translated directly to '?'. (b) the GSM standards _currently_ do define the ESC sequences as valid. I'm not really worried about current standard support in phone (as newer phones would surely conform to the current standards), but more with standard support within Kannel. and my question is (again) - which do you think is the correct implementation, Kannel's counting only actual characters, or Siemens M20's counting every septet ? P.S tests show that some phones just silently ignore the escape sequences (showing the character after the ESC - the triangle bracket), for example - the Nokia 33, and some show the intended result - the square bracket, for example - the Nokia 71. Oded Arbel m-Wise Inc. [EMAIL PROTECTED] What I can tell from EMI usage, the escape sequence stuff is slightly broken. I got customers sending \n in their text (because they've forgotton to replace it with linefeed). In kannel this translates the \ to two characters. The problem here is that it increses the size of the text and this AFTER the message has been split. The result of that is that we will end up with SMS being longer than 160 characters. So while you take a look into this, think about this fact. The final header has to be the number of octets of the SMS after escape sequences have been applied. The escape stuff is something done in the phone and the SMSC never cares about it. For the SMSC its just a stream of bytes. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
RE: A question about PDU encoding in smsc_at2
oh - I get it : the UDH is already encoded correctly using the right DCS
before the call to at2_pdu_encode(), and then at2_pdu_encode() only
needs to translate the bitstream to hex strings, and in the length
computation it computes how many septets are in the already encoded bit
stream - right ?
Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]
--
Don't ever take a fence down until you know why it was put up.
-- Robert Frost
-Original Message-
From: Andreas Fink [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 13, 2002 6:56 PM
To: Oded Arbel
Cc: [EMAIL PROTECTED]
Subject: Re: A question about PDU encoding in smsc_at2
Hi list.
I was wandering about this part from smsc_at2.c :
snip
if(octstr_len(msg-sms.udhdata)) {
if (msg-sms.coding == DC_8BIT || msg-sms.coding == DC_UCS2)
{
len += octstr_len(msg-sms.udhdata);
} else {
/* The reason we branch here is because UDH data length is
determined
in septets if we are in GSM coding, otherwise it's in
octets. Adding 6
will ensure that for an octet length of 0, we get
septet
length 0,
and for octet length 1 we get septet length 2.*/
len += (((8*octstr_len(msg-sms.udhdata)) + 6)/7);
}
}
/snip
if adds the length of the UDH differently for 7 bit then to 8 bit
encoding (as per the message coding)
snip
/* udh */
if(octstr_len(msg-sms.udhdata)) {
pos += at2_encode8bituncompressed(msg-sms.udhdata,
pdu[pos]);
}
/snip
and then always code the UDH as 8 bit.. is that OK
The final data is always octets (8bit). If the source data is 7 bit,
then its packet into octets of 8 bit. This means if you have 7 bit
data you need 7/8 less the spac on the output.
Take a look at the corresponding ITU spec.
--
Andreas Fink
Fink-Consulting
--
Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com
--
Something urgent? Try http://www.smsrelay.com/ Nickname afink
smsc_at2 module doesnot detect failed writes to modem.
well it doesn't - I can prove it :-) at2_write_line_cstr always return 0 no matter what happens. what do you say about this patch ? Oded Arbel m-Wise ltd. smsc_at2.patch Description: smsc_at2.patch
Re: smsc_at2 module doesnot detect failed writes to modem.
well it doesn't - I can prove it :-) at2_write_line_cstr always return 0 no matter what happens. what do you say about this patch ? You're right by saying at2_write_line_cstr always returns 0. I consider that a cosmetic bug. However that has absolutely no influence as the return code is nowhere used. If it can't write to the device then you will not get any from the device back either and it will fail during the next read attempt. I've cleaned the code up a little bit. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
RE: smsc_at2 module doesnot detect failed writes to modem.
Yes - but read attempts does not cause the module to give up on that modem. I think that failing to write to the modem is something which should cause kannel to give up ever trying to get the modem up to speed (for example : when the user specified an incorrect device line for the modem). maybe failing to read should also cause the module to give up ? In addition to getting at2_write_line_cstr to return a proper return code, my patch also fix at2_send_modem_command to regard a -1 return from at2_write_line_cstr as a cause for alarm and return a -1 error code, thus skipping the at2_wait_modem_command call which would have failed anyway. Oded Arbel m-Wise ltd. -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 6:43 PM To: Oded Arbel Cc: [EMAIL PROTECTED] Subject: Re: smsc_at2 module doesnot detect failed writes to modem. well it doesn't - I can prove it :-) at2_write_line_cstr always return 0 no matter what happens. what do you say about this patch ? You're right by saying at2_write_line_cstr always returns 0. I consider that a cosmetic bug. However that has absolutely no influence as the return code is nowhere used. If it can't write to the device then you will not get any from the device back either and it will fail during the next read attempt. I've cleaned the code up a little bit. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: question about smsc_AT2
Title: Re: question about smsc_AT2 hello, i ask you this question some days ago but i never got a clear answer here it is again, i would like to use smsc_at2 file but i amnot sure which file to update to tell kannel that i want to use at2 and not at could you please tell me which file it is? thanks 1. you need latest CVS version of kannel 2. you simply need to change the driver name from at to at2. Thats basically all. 3. its documented in the CVS version of the manual (its a bit hard to find it on the wepage, the URL is http://www.kannel.3glab.org/download/kannel-userguide-snapshot/userguide.html) -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
