FW: System-Type retrying on failure

Patch by Roy Walker. See below.

 

Improvement or upgrade breaker?

 

== Rene

 

 

From: Roy Walker [mailto:[email protected]] 
Sent: Tuesday, 21 September, 2010 01:02
To: Rene Kluwen
Cc: [email protected]
Subject: 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:[email protected]] 
Sent: Monday, September 20, 2010 10:27 AM
To: Roy Walker
Cc: [email protected]
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:[email protected]] 
Sent: Monday, 20 September, 2010 17:10
To: Rene Kluwen
Cc: [email protected]
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:[email protected]] 
Sent: Thursday, September 09, 2010 10:48 AM
To: Roy Walker; 'Alejandro Guerrieri'
Cc: [email protected]
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:[email protected]] 
Sent: Thursday, 09 September, 2010 17:43
To: Rene Kluwen; 'Alejandro Guerrieri'
Cc: [email protected]
Subject: RE: System-Type retrying on failure

 

Rene,

 

I wish it was that simple. we are trying to get certified by At&t 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 0x00000053 (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:[email protected]] 
Sent: Wednesday, September 08, 2010 4:01 PM
To: Roy Walker; 'Alejandro Guerrieri'
Cc: [email protected]
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:[email protected]] 
Sent: Wednesday, 08 September, 2010 22:22
To: Rene Kluwen; 'Alejandro Guerrieri'
Cc: [email protected]
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:[email protected]] 
Sent: Monday, August 23, 2010 11:04 AM
To: Roy Walker; 'Alejandro Guerrieri'
Cc: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf
Of Roy Walker
Sent: Monday, 23 August, 2010 17:45
To: Alejandro Guerrieri
Cc: [email protected]
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:[email protected]] 
Sent: Friday, August 20, 2010 4:30 PM
To: Roy Walker
Cc: [email protected]
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 <[email protected]>
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

--- kannel-snapshot/gw/smsc/smsc_smpp.c	2010-09-19 23:00:05.000000000 -0500
+++ kannel-snapshot-roy/gw/smsc/smsc_smpp.c	2010-09-20 17:36:26.000000000 -0500
@@ -1654,7 +1654,8 @@ static int handle_pdu(SMPP *smpp, Connec
                 smpp->conn->status = SMSCCONN_DISCONNECTED;
                 mutex_unlock(smpp->conn->flow_mutex);
                 if (pdu->u.bind_transmitter_resp.command_status == SMPP_ESME_RINVSYSID ||
-                    pdu->u.bind_transmitter_resp.command_status == SMPP_ESME_RINVPASWD) {
+                    pdu->u.bind_transmitter_resp.command_status == SMPP_ESME_RINVPASWD ||
+                    pdu->u.bind_transmitter_resp.command_status == SMPP_ESME_RINVSYSTYP) {
                     smpp->quitting = 1;
                 }
             } else {
@@ -1678,7 +1679,8 @@ static int handle_pdu(SMPP *smpp, Connec
                  smpp->conn->status = SMSCCONN_DISCONNECTED;
                  mutex_unlock(smpp->conn->flow_mutex);
                  if (pdu->u.bind_transceiver_resp.command_status == SMPP_ESME_RINVSYSID ||
-                     pdu->u.bind_transceiver_resp.command_status == SMPP_ESME_RINVPASWD) {
+                     pdu->u.bind_transceiver_resp.command_status == SMPP_ESME_RINVPASWD ||
+                     pdu->u.bind_transceiver_resp.command_status == SMPP_ESME_RINVSYSTYP) {
                      smpp->quitting = 1;
                  }
             } else {
@@ -1702,11 +1704,12 @@ static int handle_pdu(SMPP *smpp, Connec
                  smpp->conn->status = SMSCCONN_DISCONNECTED;
                  mutex_unlock(smpp->conn->flow_mutex);
                  if (pdu->u.bind_receiver_resp.command_status == SMPP_ESME_RINVSYSID ||
-                     pdu->u.bind_receiver_resp.command_status == SMPP_ESME_RINVPASWD) {
+                     pdu->u.bind_receiver_resp.command_status == SMPP_ESME_RINVPASWD ||
+                     pdu->u.bind_receiver_resp.command_status == SMPP_ESME_RINVSYSTYP) {
                      smpp->quitting = 1;
                  }
             } else {
-                /* set only resceive status if no transmitt is bind */
+                /* set only receive status if no transmitt is bind */
                 mutex_lock(smpp->conn->flow_mutex);
                 if (smpp->conn->status != SMSCCONN_ACTIVE) {
                     smpp->conn->status = SMSCCONN_ACTIVE_RECV;