RE: System-Type retrying on failure
Rene, Did you get any input from anyone else on added this error code? Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, September 09, 2010 10:48 AM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure In that case: Code 0x53 has to be added and handled the same way as invalid login. If the other developers agree with this, I don't mind to make a patch. It should be straightforward. == Rene From: Roy Walker [mailto:rwal...@sensorlogic.com] Sent: Thursday, 09 September, 2010 17:43 To: Rene Kluwen; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Rene, I wish it was that simple... we are trying to get certified by Att and they require us to go through a bunch of tests before they will give us a production SMPP bind. One of these tests are to have an incorrect system-type... it does not return an error 13 though... see below, but does recognize it as an Invalid system_type field: 2010-09-09 10:39:41 [12178] [11] ERROR: SMPP[Att]: SMSC rejected login to transmit, code 0x0053 (Invalid system_type field). 2010-09-09 10:39:41 [12178] [11] ERROR: SMPP[Att]: Couldn't connect to SMS center (retrying in 45 seconds). Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Wednesday, September 08, 2010 4:01 PM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Then what error is returned upon entering a wrong system-type? If it is not 0x0d (13) then it is an error in your smsc. But then again: Is it that hard to just enter the correct system-type? Once you do that, the problem will be solved. Or do I see things wrong? == Rene From: Roy Walker [mailto:rwal...@sensorlogic.com] Sent: Wednesday, 08 September, 2010 22:22 To: Rene Kluwen; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Well I had hoped that my carrier would let me slide on this, but it's not an option. It seems to me that this should be a bug... if the system-type is wrong, then kannel should fail the same way it does a bad password. As it is now the example Rene outlined below is not what it does. It retries... I created Bug #559 to track this. If you disagree or think this should not be the case please let me know. Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Monday, August 23, 2010 11:04 AM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure I think it depends on what the smsc returns as an error code. If system-type is wrong and smsc returns 0x0d (13) then it is considered wrong credentials and afaik, Kannel doesn't retry. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Roy Walker Sent: Monday, 23 August, 2010 17:45 To: Alejandro Guerrieri Cc: users@kannel.org Subject: RE: System-Type retrying on failure Should this be opened as a feature request or bug report...? Seems like a decision one way or the other... change it or make it configurable. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, August 20, 2010 4:30 PM To: Roy Walker Cc: users@kannel.org Subject: Re: System-Type retrying on failure That depends on which carrier do you ask, but yes I agree, many of them require system-type to be treated as a fatal error and not retried. Imho should be a configurable option or a compile switch at least. Regards, Alex On Fri, Aug 20, 2010 at 10:27 PM, Roy Walker rwal...@sensorlogic.commailto:rwal...@sensorlogic.com wrote: Found what some might consider a bug, but when an invalid system-type is passed on an SMPP bind, it will retry based on the reconnect-delay setting. This should be a stop failure and should work the same as an invalid smsc-username/system-id or smsc-password. Where it does not retry... right? Roy
RE: System-Type retrying on failure
Here is a patch that disables retries on an invalid system type aka 0x53 error. Please let me know if you have any issues. Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Monday, September 20, 2010 10:27 AM To: Roy Walker Cc: users@kannel.org Subject: RE: System-Type retrying on failure I have not gotten input yet. Also I am a little bit busy at the moment. Any patch is welcome. == Rene From: Roy Walker [mailto:rwal...@sensorlogic.com] Sent: Monday, 20 September, 2010 17:10 To: Rene Kluwen Cc: users@kannel.org Subject: RE: System-Type retrying on failure Rene, Did you get any input from anyone else on added this error code? Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, September 09, 2010 10:48 AM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure In that case: Code 0x53 has to be added and handled the same way as invalid login. If the other developers agree with this, I don't mind to make a patch. It should be straightforward. == Rene From: Roy Walker [mailto:rwal...@sensorlogic.com] Sent: Thursday, 09 September, 2010 17:43 To: Rene Kluwen; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Rene, I wish it was that simple... we are trying to get certified by Att and they require us to go through a bunch of tests before they will give us a production SMPP bind. One of these tests are to have an incorrect system-type... it does not return an error 13 though... see below, but does recognize it as an Invalid system_type field: 2010-09-09 10:39:41 [12178] [11] ERROR: SMPP[Att]: SMSC rejected login to transmit, code 0x0053 (Invalid system_type field). 2010-09-09 10:39:41 [12178] [11] ERROR: SMPP[Att]: Couldn't connect to SMS center (retrying in 45 seconds). Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Wednesday, September 08, 2010 4:01 PM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Then what error is returned upon entering a wrong system-type? If it is not 0x0d (13) then it is an error in your smsc. But then again: Is it that hard to just enter the correct system-type? Once you do that, the problem will be solved. Or do I see things wrong? == Rene From: Roy Walker [mailto:rwal...@sensorlogic.com] Sent: Wednesday, 08 September, 2010 22:22 To: Rene Kluwen; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Well I had hoped that my carrier would let me slide on this, but it's not an option. It seems to me that this should be a bug... if the system-type is wrong, then kannel should fail the same way it does a bad password. As it is now the example Rene outlined below is not what it does. It retries... I created Bug #559 to track this. If you disagree or think this should not be the case please let me know. Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Monday, August 23, 2010 11:04 AM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure I think it depends on what the smsc returns as an error code. If system-type is wrong and smsc returns 0x0d (13) then it is considered wrong credentials and afaik, Kannel doesn't retry. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Roy Walker Sent: Monday, 23 August, 2010 17:45 To: Alejandro Guerrieri Cc: users@kannel.org Subject: RE: System-Type retrying on failure Should this be opened as a feature request or bug report...? Seems like a decision one way or the other... change it or make it configurable. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, August 20, 2010 4:30 PM To: Roy Walker Cc: users@kannel.org Subject: Re: System-Type retrying on failure That depends on which carrier do you ask, but yes I agree, many of them require system-type to be treated as a fatal error and not retried. Imho should be a configurable option or a compile switch at least. Regards, Alex On Fri, Aug 20, 2010 at 10:27 PM, Roy Walker rwal...@sensorlogic.commailto:rwal...@sensorlogic.com wrote: Found what some might consider a bug, but when an invalid system-type is passed on an SMPP bind, it will retry based on the reconnect-delay setting. This should be a stop failure and should work the same as an invalid smsc-username/system-id or smsc-password. Where it does not retry... right? Roy system-type-no-retry.patch Description: system-type-no-retry.patch
RE: System-Type retrying on failure
Rene, I wish it was that simple... we are trying to get certified by Att and they require us to go through a bunch of tests before they will give us a production SMPP bind. One of these tests are to have an incorrect system-type... it does not return an error 13 though... see below, but does recognize it as an Invalid system_type field: 2010-09-09 10:39:41 [12178] [11] ERROR: SMPP[Att]: SMSC rejected login to transmit, code 0x0053 (Invalid system_type field). 2010-09-09 10:39:41 [12178] [11] ERROR: SMPP[Att]: Couldn't connect to SMS center (retrying in 45 seconds). Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Wednesday, September 08, 2010 4:01 PM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Then what error is returned upon entering a wrong system-type? If it is not 0x0d (13) then it is an error in your smsc. But then again: Is it that hard to just enter the correct system-type? Once you do that, the problem will be solved. Or do I see things wrong? == Rene From: Roy Walker [mailto:rwal...@sensorlogic.com] Sent: Wednesday, 08 September, 2010 22:22 To: Rene Kluwen; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure Well I had hoped that my carrier would let me slide on this, but it's not an option. It seems to me that this should be a bug... if the system-type is wrong, then kannel should fail the same way it does a bad password. As it is now the example Rene outlined below is not what it does. It retries... I created Bug #559 to track this. If you disagree or think this should not be the case please let me know. Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Monday, August 23, 2010 11:04 AM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure I think it depends on what the smsc returns as an error code. If system-type is wrong and smsc returns 0x0d (13) then it is considered wrong credentials and afaik, Kannel doesn't retry. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Roy Walker Sent: Monday, 23 August, 2010 17:45 To: Alejandro Guerrieri Cc: users@kannel.org Subject: RE: System-Type retrying on failure Should this be opened as a feature request or bug report...? Seems like a decision one way or the other... change it or make it configurable. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, August 20, 2010 4:30 PM To: Roy Walker Cc: users@kannel.org Subject: Re: System-Type retrying on failure That depends on which carrier do you ask, but yes I agree, many of them require system-type to be treated as a fatal error and not retried. Imho should be a configurable option or a compile switch at least. Regards, Alex On Fri, Aug 20, 2010 at 10:27 PM, Roy Walker rwal...@sensorlogic.commailto:rwal...@sensorlogic.com wrote: Found what some might consider a bug, but when an invalid system-type is passed on an SMPP bind, it will retry based on the reconnect-delay setting. This should be a stop failure and should work the same as an invalid smsc-username/system-id or smsc-password. Where it does not retry... right? Roy
RE: System-Type retrying on failure
Well I had hoped that my carrier would let me slide on this, but it's not an option. It seems to me that this should be a bug... if the system-type is wrong, then kannel should fail the same way it does a bad password. As it is now the example Rene outlined below is not what it does. It retries... I created Bug #559 to track this. If you disagree or think this should not be the case please let me know. Thanks, Roy From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Monday, August 23, 2010 11:04 AM To: Roy Walker; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: System-Type retrying on failure I think it depends on what the smsc returns as an error code. If system-type is wrong and smsc returns 0x0d (13) then it is considered wrong credentials and afaik, Kannel doesn't retry. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Roy Walker Sent: Monday, 23 August, 2010 17:45 To: Alejandro Guerrieri Cc: users@kannel.org Subject: RE: System-Type retrying on failure Should this be opened as a feature request or bug report...? Seems like a decision one way or the other... change it or make it configurable. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, August 20, 2010 4:30 PM To: Roy Walker Cc: users@kannel.org Subject: Re: System-Type retrying on failure That depends on which carrier do you ask, but yes I agree, many of them require system-type to be treated as a fatal error and not retried. Imho should be a configurable option or a compile switch at least. Regards, Alex On Fri, Aug 20, 2010 at 10:27 PM, Roy Walker rwal...@sensorlogic.commailto:rwal...@sensorlogic.com wrote: Found what some might consider a bug, but when an invalid system-type is passed on an SMPP bind, it will retry based on the reconnect-delay setting. This should be a stop failure and should work the same as an invalid smsc-username/system-id or smsc-password. Where it does not retry... right? Roy
RE: System-Type retrying on failure
Should this be opened as a feature request or bug report...? Seems like a decision one way or the other... change it or make it configurable. From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, August 20, 2010 4:30 PM To: Roy Walker Cc: users@kannel.org Subject: Re: System-Type retrying on failure That depends on which carrier do you ask, but yes I agree, many of them require system-type to be treated as a fatal error and not retried. Imho should be a configurable option or a compile switch at least. Regards, Alex On Fri, Aug 20, 2010 at 10:27 PM, Roy Walker rwal...@sensorlogic.commailto:rwal...@sensorlogic.com wrote: Found what some might consider a bug, but when an invalid system-type is passed on an SMPP bind, it will retry based on the reconnect-delay setting. This should be a stop failure and should work the same as an invalid smsc-username/system-id or smsc-password. Where it does not retry... right? Roy
System-Type retrying on failure
Found what some might consider a bug, but when an invalid system-type is passed on an SMPP bind, it will retry based on the reconnect-delay setting. This should be a stop failure and should work the same as an invalid smsc-username/system-id or smsc-password. Where it does not retry... right? Roy
RE: Program-ID
Is there a plan for the next stable release? My concern with grabbing a version out of SVN is that is has been a LONG time since the last stable release and there are probably quite a few changes... Roy -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Juan Nin Sent: Monday, August 16, 2010 12:54 PM To: users@kannel.org Subject: Re: Program-ID Well, I guess Roy is talking about US carriers, where ATT has been using Program-IDs, now T-Mobile started using 3PG a few months ago where they require a Program-ID, and now Verizon is also requiring a Program-ID. Depending on the gateway you're using you may need to specify a Program ID on your MTs (e.g. with OpenMarket), or others abstract you from it (e.g. MX Telecom). But program ids need to be registered with the carriers for your campaigns anyway, which the gateway takes care of it. On the cases where you need to specify a Program ID on your MTs, you just do it via an SMPP Optional Parameter (TLV), using the meta-data parameter as Alex mentioned. Regards, Juan On Mon, Aug 16, 2010 at 1:37 PM, Alejandro Guerrieri alejandro.guerri...@gmail.com wrote: At least on SMPP, there's not such a parameter. If you're talking about an optional parameter (TLV), I seriously doubt it's an all major carriers thing (they don't usually agree on that kind of stuff), but probably something the aggregator you're using added to abstract something the carriers he connected to requires. If that's the case, you can easily add support for it by using the latest SVN and configuring meta-data to add the optional parameter. Check the user guide for further information. Regards, Alex On Mon, Aug 16, 2010 at 6:02 PM, Roy Walker rwal...@sensorlogic.com wrote: Looks like all the major carriers are requiring a program-id to be sent on each SMPP message. Is this possible in the current devel or stable version of Kannel? Currently running 1.4.3. If not, is there plans to add it? Thanks, Roy -- Juan Nin 3Cinteractive / Mobilizing Great Brands http://www.3cinteractive.com
unsubscribe
Please help
Still having a steep learning curve on this... Getting error like this: 2008-09-23 13:11:01 [29782] [8] DEBUG: boxc_receiver: sms received 2008-09-23 13:11:01 [29782] [8] WARNING: Cannot find SMSCConn for message to 214555, rejected. 2008-09-23 13:11:01 [29782] [8] WARNING: Message rejected by bearerbox, no router! 2008-09-23 13:11:01 [29782] [8] DEBUG: send_msg: sending msg to box: 127.0.0.1 Here is the config: group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar #status-password = foo #admin-deny-ip = #admin-allow-ip = log-file = /var/log/kannel/core.log log-level = 0 #box-deny-ip = *.*.*.* box-allow-ip = *.*.*.* #unified-prefix = +358,00358,0;+,00 access-log = /var/log/kannel/core-access.log #store-file = kannel.store #ssl-server-cert-file = cert.pem #ssl-server-key-file = key.pem #ssl-certkey-file = mycertandprivkeyfile.pem #- # SMSC CONNECTIONS # # SMSC connections are created in bearerbox and they handle SMSC specific # protocol and message relying. You need these to actually receive and send # messages to handset, but can use GSM modems as virtual SMSCs # USB attached GSM phone group = smsc smsc = at smsc-id = motorola allowed-smsc-id = motorola modemtype = motorola device = /dev/ttyACM0 speed = 115200 my-number = 13616961548 log-file = /var/log/kannel/gsm-smsc.log log-level = 0 sim-buffering = false connect-allow-ip = *.*.*.* group = modems id = motorola name = motorola detect-string = MOTOROLA speed = 115200 init-string = ATF Q0 V1 E0 S0=0 D2 C1;+CNMI=3,2,0,0,0;+CMEE=2 need-sleep = true #init-string = AT+CGDCONT=1,IP,slogic.t-mobile.net #- # SMSBOX SETUP # # Smsbox(es) do higher-level SMS handling after they have been received from # SMS centers by bearerbox, or before they are given to bearerbox for delivery group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 global-sender = 13616961548 #sendsms-chars = 0123456789 +- log-file = /var/log/kannel/smsbox.log log-level = 0 access-log = /var/log/kannel/smsbox-access.log #- # SEND-SMS USERS # # These users are used when Kannel smsbox sendsms interface is used to # send PUSH sms messages, i.e. calling URL like # http://kannel.machine:13013/cgi-bin/sendsms?username=testerpassword=foo bar... group = sendsms-user username = kannelsms password = password #- # SERVICES # # These are 'responses' to sms PULL messages, i.e. messages arriving from # handsets. The response is based on message content. Only one sms-service is # applied, using the first one to match. group = sms-service keyword = nop text = You asked nothing and I did it! # There should be always a 'default' service. This service is used when no # other 'sms-service' is applied. group = sms-service keyword = default text = No service specified
RE: Please help
Taking out the my number line from the SMSC config did not change anything. Getting the same error. Since I don't want to filter, I don't see a reason to specify the allowed-prefix line. Any other ideas? Thanks, Roy -Original Message- From: Eduardo Raad [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 1:42 PM To: Roy Walker Cc: users@kannel.org Subject: Re: Please help The error message is telling you that the bearerbox could not find a valid route for that number. I'm not sure why this is happening as I'm using a similar configuration (without specifying actual accepted prefixes on the SMSC config) and it works for me. You may try to remove the my number parameter from the SMSC or add accepted prefixes to the SMSC. Look for this on the user guide. Eduardo Roy Walker wrote: Still having a steep learning curve on this... Getting error like this: 2008-09-23 13:11:01 [29782] [8] DEBUG: boxc_receiver: sms received 2008-09-23 13:11:01 [29782] [8] WARNING: Cannot find SMSCConn for message to 214555, rejected. 2008-09-23 13:11:01 [29782] [8] WARNING: Message rejected by bearerbox, no router! 2008-09-23 13:11:01 [29782] [8] DEBUG: send_msg: sending msg to box: 127.0.0.1 Here is the config: group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar #status-password = foo #admin-deny-ip = #admin-allow-ip = log-file = /var/log/kannel/core.log log-level = 0 #box-deny-ip = *.*.*.* box-allow-ip = *.*.*.* #unified-prefix = +358,00358,0;+,00 access-log = /var/log/kannel/core-access.log #store-file = kannel.store #ssl-server-cert-file = cert.pem #ssl-server-key-file = key.pem #ssl-certkey-file = mycertandprivkeyfile.pem #- # SMSC CONNECTIONS # # SMSC connections are created in bearerbox and they handle SMSC specific # protocol and message relying. You need these to actually receive and send # messages to handset, but can use GSM modems as virtual SMSCs # USB attached GSM phone group = smsc smsc = at smsc-id = motorola allowed-smsc-id = motorola modemtype = motorola device = /dev/ttyACM0 speed = 115200 my-number = 13616961548 log-file = /var/log/kannel/gsm-smsc.log log-level = 0 sim-buffering = false connect-allow-ip = *.*.*.* group = modems id = motorola name = motorola detect-string = MOTOROLA speed = 115200 init-string = ATF Q0 V1 E0 S0=0 D2 C1;+CNMI=3,2,0,0,0;+CMEE=2 need-sleep = true #init-string = AT+CGDCONT=1,IP,slogic.t-mobile.net #- # SMSBOX SETUP # # Smsbox(es) do higher-level SMS handling after they have been received from # SMS centers by bearerbox, or before they are given to bearerbox for delivery group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 global-sender = 13616961548 #sendsms-chars = 0123456789 +- log-file = /var/log/kannel/smsbox.log log-level = 0 access-log = /var/log/kannel/smsbox-access.log #- # SEND-SMS USERS # # These users are used when Kannel smsbox sendsms interface is used to # send PUSH sms messages, i.e. calling URL like # http://kannel.machine:13013/cgi-bin/sendsms?username=testerpassword=foo bar... group = sendsms-user username = kannelsms password = password #- # SERVICES # # These are 'responses' to sms PULL messages, i.e. messages arriving from # handsets. The response is based on message content. Only one sms-service is # applied, using the first one to match. group = sms-service keyword = nop text = You asked nothing and I did it! # There should be always a 'default' service. This service is used when no # other 'sms-service' is applied. group = sms-service keyword = default text = No service specified
RE: Please help
THANK YOU That worked great. Is there any way to set a default smsc so that if one is not specified it will use it? Roy From: Alejandro Guerrieri [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 2:57 PM To: Roy Walker Cc: Eduardo Raad; users@kannel.org Subject: Re: Please help Try adding the smsc parameter to the sendsms URL to force using that route. For example: http://host:port/cgi-bin/sendsms?username=testerpassword=foobarfrom... smsc=motorola Regards, Alejandro On Tue, Sep 23, 2008 at 4:07 PM, Roy Walker [EMAIL PROTECTED] wrote: Taking out the my number line from the SMSC config did not change anything. Getting the same error. Since I don't want to filter, I don't see a reason to specify the allowed-prefix line. Any other ideas? Thanks, Roy -Original Message- From: Eduardo Raad [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 1:42 PM To: Roy Walker Cc: users@kannel.org Subject: Re: Please help The error message is telling you that the bearerbox could not find a valid route for that number. I'm not sure why this is happening as I'm using a similar configuration (without specifying actual accepted prefixes on the SMSC config) and it works for me. You may try to remove the my number parameter from the SMSC or add accepted prefixes to the SMSC. Look for this on the user guide. Eduardo Roy Walker wrote: Still having a steep learning curve on this... Getting error like this: 2008-09-23 13:11:01 [29782] [8] DEBUG: boxc_receiver: sms received 2008-09-23 13:11:01 [29782] [8] WARNING: Cannot find SMSCConn for message to 214555, rejected. 2008-09-23 13:11:01 [29782] [8] WARNING: Message rejected by bearerbox, no router! 2008-09-23 13:11:01 [29782] [8] DEBUG: send_msg: sending msg to box: 127.0.0.1 Here is the config: group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar #status-password = foo #admin-deny-ip = #admin-allow-ip = log-file = /var/log/kannel/core.log log-level = 0 #box-deny-ip = *.*.*.* box-allow-ip = *.*.*.* #unified-prefix = +358,00358,0;+,00 access-log = /var/log/kannel/core-access.log #store-file = kannel.store #ssl-server-cert-file = cert.pem #ssl-server-key-file = key.pem #ssl-certkey-file = mycertandprivkeyfile.pem #- # SMSC CONNECTIONS # # SMSC connections are created in bearerbox and they handle SMSC specific # protocol and message relying. You need these to actually receive and send # messages to handset, but can use GSM modems as virtual SMSCs # USB attached GSM phone group = smsc smsc = at smsc-id = motorola allowed-smsc-id = motorola modemtype = motorola device = /dev/ttyACM0 speed = 115200 my-number = 13616961548 log-file = /var/log/kannel/gsm-smsc.log log-level = 0 sim-buffering = false connect-allow-ip = *.*.*.* group = modems id = motorola name = motorola detect-string = MOTOROLA speed = 115200 init-string = ATF Q0 V1 E0 S0=0 D2 C1;+CNMI=3,2,0,0,0;+CMEE=2 need-sleep = true #init-string = AT+CGDCONT=1,IP,slogic.t-mobile.net #- # SMSBOX SETUP # # Smsbox(es) do higher-level SMS handling after they have been received from # SMS centers by bearerbox, or before they are given to bearerbox for delivery group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 global-sender = 13616961548 #sendsms-chars = 0123456789 +- log-file = /var/log/kannel/smsbox.log log-level = 0 access-log = /var/log/kannel/smsbox-access.log #- # SEND-SMS USERS # # These users are used when Kannel smsbox sendsms interface is used to # send PUSH sms messages, i.e. calling URL like # http://kannel.machine:13013/cgi-bin/sendsms?username=testerpassword=foo bar... group = sendsms-user username = kannelsms password = password #- # SERVICES # # These are 'responses' to sms PULL messages, i.e. messages arriving from # handsets. The response is based on message content. Only one sms-service is # applied, using the first one to match. group = sms-service keyword = nop text = You asked nothing and I did it! # There should be always a 'default' service. This service is used when no # other 'sms-service' is applied. group = sms-service keyword = default text = No service specified
Sendsms error with motorola phone
Getting an error when trying to send a sms through a web call. The phone hooked up to the USB port is a Motorola Pebl. After running the following command: Wget http://localhost:13013/cgi-bin/sendsms?username=kannelsmspassword=passw ordfrom=13616961548to=2145551212text=test' Getting this in my core.log file: 2008-09-18 15:55:22 [15951] [14] DEBUG: HTTP: Opening connection to `localhost:13013' (fd=44). 2008-09-18 15:55:22 [15951] [14] DEBUG: Socket connecting 2008-09-18 15:55:22 [15951] [13] DEBUG: Get info about connecting socket 2008-09-18 15:55:22 [15951] [13] DEBUG: HTTP: Sending request: 2008-09-18 15:55:22 [15951] [13] DEBUG: Octet string at 0x8a06e88: 2008-09-18 15:55:22 [15951] [13] DEBUG: len: 153 2008-09-18 15:55:22 [15951] [13] DEBUG: size: 1024 2008-09-18 15:55:22 [15951] [13] DEBUG: immutable: 0 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 47 45 54 20 2f 63 67 69 2d 62 69 6e 2f 73 65 6e GET /cgi-bin/sen 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 64 73 6d 73 3f 75 73 65 72 6e 61 6d 65 3d 6b 61 dsms?username=ka 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 6e 6e 65 6c 68 74 74 70 26 70 61 73 73 77 6f 72 nnelhttppasswor 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 64 3d 70 61 73 73 77 6f 72 64 26 74 6f 3d 32 31 d=passwordto=21 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 34 32 32 33 37 30 37 39 26 74 65 78 74 3d 74 65 42237079text=te 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 73 74 26 66 72 6f 6d 3d 31 33 36 31 36 39 36 31 stfrom=13616961 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 35 34 38 26 63 6f 64 69 6e 67 3d 30 26 64 6c 72 548coding=0dlr 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 2d 75 72 6c 3d 20 48 54 54 50 2f 31 2e 31 0d 0a -url= HTTP/1.1.. 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f 73 74 3a Host: localhost: 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 31 33 30 31 33 0d 0a 0d 0a13013 2008-09-18 15:55:22 [15951] [13] DEBUG: Octet string dump ends. 2008-09-18 15:55:22 [15951] [13] DEBUG: HTTP: Status line: HTTP/1.1 403 Forbidden 2008-09-18 15:55:22 [15951] [13] DEBUG: HTTP: Received response: 2008-09-18 15:55:22 [15951] [13] DEBUG: Octet string at 0x8a06ea8: 2008-09-18 15:55:22 [15951] [13] DEBUG: len: 144 2008-09-18 15:55:22 [15951] [13] DEBUG: size: 1024 2008-09-18 15:55:22 [15951] [13] DEBUG: immutable: 0 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 53 65 72 76 65 72 3a 20 4b 61 6e 6e 65 6c 2f 31 Server: Kannel/1 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 2e 34 2e 31 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 .4.1..Content-Le 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 6e 67 74 68 3a 20 33 32 0d 0a 43 6f 6e 74 65 6e ngth: 32..Conten 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 74 2d 74 79 70 65 3a 20 74 65 78 74 2f 68 74 6d t-type: text/htm 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 6c 0d 0a 50 72 61 67 6d 61 3a 20 6e 6f 2d 63 61 l..Pragma: no-ca 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 63 68 65 0d 0a 43 61 63 68 65 2d 43 6f 6e 74 72 che..Cache-Contr 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 6f 6c 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a ol: no-cache 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 41 75 74 68 6f 72 69 7a 61 74 69 6f 6e 20 66 61 Authorization fa 2008-09-18 15:55:22 [15951] [13] DEBUG: data: 69 6c 65 64 20 66 6f 72 20 73 65 6e 64 73 6d 73 iled for sendsms 2008-09-18 15:55:22 [15951] [13] DEBUG: Octet string dump ends. 2008-09-18 15:56:22 [15951] [13] DEBUG: HTTP: Server closed connection, destroying it localhost:130130x89f9bb8fd:44. Here is the kannel.conf file: group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar #status-password = foo #admin-deny-ip = #admin-allow-ip = log-file = /var/log/kannel/core.log log-level = 0 #box-deny-ip = *.*.*.* box-allow-ip = *.*.*.* #unified-prefix = +358,00358,0;+,00 access-log = /var/log/kannel/core-access.log #store-file = kannel.store #ssl-server-cert-file = cert.pem #ssl-server-key-file = key.pem #ssl-certkey-file = mycertandprivkeyfile.pem group = smsc smsc = fake smsc-id = FAKE port = 1 #connect-allow-ip = 127.0.0.1 # HTTP gateway to SMS-C group = smsc smsc = http system-type = kannel smsc-id = http port = 15130 connect-allow-ip = *.*.*.* smsc-username = kannelhttp smsc-password = password send-url = http://localhost:13013/cgi-bin/sendsms; log-file = /var/log/kannel/http-smsc.log log-level = 0 # USB attached GSM phone group = smsc smsc = at smsc-id = motorola allowed-smsc-id = motorola modemtype = motorola device = /dev/ttyACM0 speed = 115200 my-number = 13616961548 log-file = /var/log/kannel/gsm-smsc.log log-level = 0 sim-buffering = false connect-allow-ip = *.*.*.* group = modems id = motorola name = motorola detect-string = MOTOROLA speed = 115200 init-string = ATF Q0 V1 E0 S0=0 D2
