Hi,
you have forgot mutex_[lock|unlock] to protect status var. I added it
and committed your patch.
Thanks,
Alex
Peter Christensen schrieb:
Hi,
Apparently fixing that was quite easy. When the SMPP thread escapes the
while (!smpp->quitting) loop, I set state to SMSCCONN_DEAD
Med venlig hilsen / Best regards
Peter Christensen
Developer
------------------
Cool Systems ApS
Tel: +45 2888 1600
@ : [EMAIL PROTECTED]
www: www.coolsystems.dk
Peter Christensen wrote:
Hi,
Yes, I agree that the behavior is the ideal one. But I think it is
confusing to the user that the log says "Re-connecting" and bearerbox
reports the state of the gateway as "reconnecting" (When requesting
status/status.xml/status.html), while it should actually be dead.
Alexander Malysh wrote:
Hi,
yes it really intentional. if SMSC returns such error and your
system_id/password are correct then it's SMSC bug! Imagine SMSC could
not retrieve your login data for some reason it should never claim
your system_id or password is wrong (for this purpose exists Bind
Failed)!
Why kannel has such behavior: because some SMSCs suspend (security
issue) your account when you unintentionally supplied wrong system_id
or password. And then you have to contact support and explain
something etc. etc. It's just good behavior to not to abuse SMSC...
Thanks,
Alex
Peter Christensen schrieb:
Hi,
I've been experiencing problems where kannel at some time no longer
attempts to reconnect a gateway, which is down. Here's what
basically happens (gateway name and address is replaced with fake
name/address):
ERROR: System error 111: Connection refused
ERROR: error connecting to server `1.2.3.4' at port `2775'
ERROR: SMPP[gateway]: Couldn't connect to server.
ERROR: SMPP[gateway]: Couldn't connect to SMS center (retrying in 10
seconds).
ERROR: connect failed
ERROR: System error 111: Connection refused
ERROR: error connecting to server `1.2.3.4' at port `2775'
ERROR: SMPP[gateway]: Couldn't connect to server.
ERROR: SMPP[gateway]: Couldn't connect to SMS center (retrying in 10
seconds).
WARNING: SMPP: PDU NULL terminated string has no NULL.
ERROR: SMPP[gateway]: SMSC rejected login to transmit, code
0x0000000f (Invalid System ID).
ERROR: SMPP[gateway]: I/O error or other error. Re-connecting.
Although kannel claim to be reconnect when the login was invalid,
this never occurs. The thread terminates, but bearerbox still report
the state of the gateway as "reconnecting".
When examining the code, it is very obvious that the SMPP gateway
code is meant to terminate when login is rejected:
gateway/gw/smsc/smsc_smpp.c:1468
if (pdu->u.bind_transmitter_resp.command_status ==
SMPP_ESME_RINVSYSID ||
pdu->u.bind_transmitter_resp.command_status ==
SMPP_ESME_RINVPASWD)
smpp->quitting = 1;
gateway/gw/smsc/smsc_smpp.c:1488
if (pdu->u.bind_transceiver_resp.command_status ==
SMPP_ESME_RINVSYSID ||
pdu->u.bind_transceiver_resp.command_status ==
SMPP_ESME_RINVPASWD)
smpp->quitting = 1;
Is this really intentional? And if so, isn't it then wrong to say
claim that kannel will reconnect?
Med venlig hilsen / Best regards
Peter Christensen
Developer
------------------
Cool Systems ApS
Tel: +45 2888 1600
@ : [EMAIL PROTECTED]
www: www.coolsystems.dk
------------------------------------------------------------------------
diff -Nru gateway/gw/smsc/smsc_smpp.c gateway.dead/gw/smsc/smsc_smpp.c
--- gateway/gw/smsc/smsc_smpp.c 2005-12-18 21:21:16.000000000 +0100
+++ gateway.dead/gw/smsc/smsc_smpp.c 2006-01-19 10:48:50.000000000 +0100
@@ -1840,6 +1840,8 @@
gwthread_sleep(smpp->conn->reconnect_delay);
}
}
+
+ smpp->conn->status = SMSCCONN_DEAD;
}