Re: bug in smsc_smpp.c login failure
Alan McNatty wrote: On Thu, 2003-02-27 at 18:54, Nisan Bloch wrote: Hi At 03:46 PM 2/27/03 +1300, Alan McNatty wrote: Hello, found that if I type in the smpp password incorrectly kannel loops forever trying to reconnect. ie: -1 from me In the current form this path will not allow any retries for any sort of bind error. eg what happens if there is a temporary connectivity issue, or the SMPP server is down for a short while/ What I'm trying highlight is that there is a gap in logic .. Currently regardless of the type of error we continually retry to bind. If we specifically receive an error indicating the password is invalid the SMSC is obviously up but we may as well kill the thread. yep, that's true in some sense. Trying to reconnect forever while we get the error information from the SMSC that we can't login with that credentials *could* be considered as login abuse :) At least I would consider this if our SMPP clients would hammer our SMPP server with invalid credentials. 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: bug in smsc_smpp.c login failure
Hi,
what about attached patch ?
Am Donnerstag, 27. Februar 2003 10:30 schrieb Stipe Tolj:
Alan McNatty wrote:
On Thu, 2003-02-27 at 18:54, Nisan Bloch wrote:
Hi
At 03:46 PM 2/27/03 +1300, Alan McNatty wrote:
Hello,
found that if I type in the smpp password incorrectly kannel loops
forever trying to reconnect. ie:
-1 from me
In the current form this path will not allow any retries for any sort
of bind error. eg what happens if there is a temporary connectivity
issue, or the SMPP server is down for a short while/
What I'm trying highlight is that there is a gap in logic ..
Currently regardless of the type of error we continually retry to bind.
If we specifically receive an error indicating the password is invalid
the SMSC is obviously up but we may as well kill the thread.
yep, that's true in some sense. Trying to reconnect forever while we
get the error information from the SMSC that we can't login with that
credentials *could* be considered as login abuse :)
At least I would consider this if our SMPP clients would hammer our
SMPP server with invalid credentials.
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
--
Best regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 240
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
msn: [EMAIL PROTECTED]
icq: 98063111
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.25
diff -a -u -r1.25 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 23 Feb 2003 11:35:34 - 1.25
+++ gw/smsc/smsc_smpp.c 27 Feb 2003 10:25:35 -
@@ -62,6 +62,8 @@
*/
enum {
+SMPP_ESME_RINVPASWD = 0x000E,
+SMPP_ESME_RINVSYSID = 0x000F,
SMPP_ESME_RMSGQFUL= 0x0014,
SMPP_ESME_RTHROTTLED = 0x0058,
SMPP_ESME_RX_T_APPN = 0x0064,
@@ -958,6 +960,9 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transmitter_resp.command_status);
+if (pdu-u.bind_transmitter_resp.command_status == SMPP_ESME_RINVSYSID ||
+pdu-u.bind_transmitter_resp.command_status == SMPP_ESME_RINVPASWD)
+smpp-quitting = 1;
} else {
*pending_submits = 0;
smpp-conn-status = SMSCCONN_ACTIVE;
@@ -972,6 +977,9 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transceiver_resp.command_status);
+if (pdu-u.bind_transceiver_resp.command_status == SMPP_ESME_RINVSYSID ||
+pdu-u.bind_transceiver_resp.command_status == SMPP_ESME_RINVPASWD)
+smpp-quitting = 1;
} else {
*pending_submits = 0;
smpp-conn-status = SMSCCONN_ACTIVE;
@@ -986,6 +994,9 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_receiver_resp.command_status);
+if (pdu-u.bind_receiver_resp.command_status == SMPP_ESME_RINVSYSID ||
+pdu-u.bind_receiver_resp.command_status == SMPP_ESME_RINVPASWD)
+smpp-quitting = 1;
} else {
/* set only resceive status if no transmitt is bind */
if (smpp-conn-status != SMSCCONN_ACTIVE) {
Re: bug in smsc_smpp.c login failure
hi yeah.. great +1 nisan At 11:27 AM 2/27/03 +0100, Alexander Malysh wrote: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from 8bit to quoted-printable by mail-in-01.piro.net id LAA28081 Hi, what about attached patch ? Am Donnerstag, 27. Februar 2003 10:30 schrieb Stipe Tolj: Alan McNatty wrote: On Thu, 2003-02-27 at 18:54, Nisan Bloch wrote: Hi At 03:46 PM 2/27/03 +1300, Alan McNatty wrote: Hello, found that if I type in the smpp password incorrectly kannel loops forever trying to reconnect. ie: -1 from me In the current form this path will not allow any retries for any sort of bind error. eg what happens if there is a temporary connectivity issue, or the SMPP server is down for a short while/ What I'm trying highlight is that there is a gap in logic .. Currently regardless of the type of error we continually retry to bind. If we specifically receive an error indicating the password is invalid the SMSC is obviously up but we may as well kill the thread. yep, that's true in some sense. Trying to reconnect forever while we get the error information from the SMSC that we can't login with that credentials *could* be considered as login abuse :) At least I would consider this if our SMPP clients would hammer our SMPP server with invalid credentials. 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 -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED] icq: 98063111
bug in smsc_smpp.c login failure
Hello,
found that if I type in the smpp password incorrectly kannel loops
forever trying to reconnect. ie:
[6] DEBUG: SMPP PDU 0x80f3a18 dump:
[6] DEBUG: type_name: bind_receiver_resp
[6] DEBUG: command_id: 2147483649 = 0x8001
[6] DEBUG: command_status: 14 = 0x000e
[6] DEBUG: sequence_number: 732 = 0x02dc
[6] DEBUG: system_id: NULL
[6] DEBUG: SMPP PDU dump ends.
[6] ERROR: SMPP[xxx]: SMSC rejected login to receive, code 0x000e.
[6] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting.
And so on ..
The smsc_smpp.c handle_pdu notices the error (and indeed reports on it)
but it's not noticed at the io_thread level so keeps trying.
I worked around it by setting smpp-quitting = 1 after the error message
in handle_pdu (see patch) which has the effect of shutting down the
failing threads (so they don't keep trying). Crude - provided as example
only - will look at improving this.
Also, in the instance you only have 1 smpp connection which when fails
in this way, the bearerbox sits without actually shutting down (ie:
doesn't realise there are no active threads and clean up, etc). Should
the bearerbox shutdown in this instance?
Cheers,
Alan
--
Alan McNatty [EMAIL PROTECTED]
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.25
diff -u -r1.25 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 23 Feb 2003 11:35:34 - 1.25
+++ gw/smsc/smsc_smpp.c 27 Feb 2003 02:29:38 -
@@ -958,6 +958,11 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transmitter_resp.command_status);
+
+ /* Need to die here, well just don't keep trying this connection
+ * if the password doesn't work it never will */
+ smpp-quitting = 1;
+
} else {
*pending_submits = 0;
smpp-conn-status = SMSCCONN_ACTIVE;
Re: bug in smsc_smpp.c login failure
Hi At 03:46 PM 2/27/03 +1300, Alan McNatty wrote: Hello, found that if I type in the smpp password incorrectly kannel loops forever trying to reconnect. ie: -1 from me In the current form this path will not allow any retries for any sort of bind error. eg what happens if there is a temporary connectivity issue, or the SMPP server is down for a short while/ Nisan [6] DEBUG: SMPP PDU 0x80f3a18 dump: [6] DEBUG: type_name: bind_receiver_resp [6] DEBUG: command_id: 2147483649 = 0x8001 [6] DEBUG: command_status: 14 = 0x000e [6] DEBUG: sequence_number: 732 = 0x02dc [6] DEBUG: system_id: NULL [6] DEBUG: SMPP PDU dump ends. [6] ERROR: SMPP[xxx]: SMSC rejected login to receive, code 0x000e. [6] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting. And so on .. The smsc_smpp.c handle_pdu notices the error (and indeed reports on it) but it's not noticed at the io_thread level so keeps trying. I worked around it by setting smpp-quitting = 1 after the error message in handle_pdu (see patch) which has the effect of shutting down the failing threads (so they don't keep trying). Crude - provided as example only - will look at improving this. Also, in the instance you only have 1 smpp connection which when fails in this way, the bearerbox sits without actually shutting down (ie: doesn't realise there are no active threads and clean up, etc). Should the bearerbox shutdown in this instance? Cheers, Alan -- Alan McNatty [EMAIL PROTECTED]
Re: bug in smsc_smpp.c login failure
On Thu, 2003-02-27 at 18:54, Nisan Bloch wrote: Hi At 03:46 PM 2/27/03 +1300, Alan McNatty wrote: Hello, found that if I type in the smpp password incorrectly kannel loops forever trying to reconnect. ie: -1 from me In the current form this path will not allow any retries for any sort of bind error. eg what happens if there is a temporary connectivity issue, or the SMPP server is down for a short while/ What I'm trying highlight is that there is a gap in logic .. Currently regardless of the type of error we continually retry to bind. If we specifically receive an error indicating the password is invalid the SMSC is obviously up but we may as well kill the thread. ie: 'I/O error or other error. Re-connecting' is not the right approach for some errors. I haven't supplied a fix yet (no +/- required yet), the diff I supplied was to highlight the location of the bug.
