Hi Alex,
I assume you would accept Stripe's patch if the following are done:
1. The Kannel User guide should have the reset-string in
<literal>reset-string</literal> replaced with max-error-count.
2. Since the reason the connection is dead is already stored in
why_killed
(SMSCConn struct), it should be exported via a status call.
Please confirm if there is anything else?
Rgds
Date: Fri, 17 Apr 2009 14:17:58 +0200
From: Alexander Malysh <[email protected]>
Subject: Re: [PATCH] SMSC AT - detecting dead SIMs
To: Stipe Tolj <[email protected]>
Cc: kannel_dev_mailinglist <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
patch looks OK except userguide:
--- doc/userguide/userguide.xml 15 Feb 2009 23:13:55 -0000 1.345
+++ doc/userguide/userguide.xml 8 Apr 2009 19:42:07 -0000
@@ -3708,8 +3708,13 @@
<entry><literal>integer</literal></entry>
<entry valign="bottom">
Maximal error count for opening modem device or
initializing of
the modem before
- <literal>reset-string</literal> will be executed. This is
useful
when modem crashed and needs
- hard reset. Default disabled.
+ <literal>reset-string</literal> will be executed.
^^^^^^^^^^^ it should be max-error-count
+ This is useful when modem crashed and needs hard reset.
Default
disabled.
+ Also used as maximum value for successive generic errors
from the
modem while
+ PDUs are passed. If we hit this thresshold we will assume
that
the SIM card
+ in the modem is not functional anymore, and shutdown the
smsc
group. The
+ HTTP admin status page will show this modem as 'dead' in
the
status. So
+ corresponding system admins and/or monitoring components
can take
action.
</entry></row>
Thanks,
Alex
P.S. As for the why connection is dead we have already why_killed in
SMSCConn struct. We should just export it via
status call.
2009/4/8 Stipe Tolj <[email protected]>
Hi list,
we had a recent demand in a GSM modem pool to detect SIM cards in
the GSM
modems
that have been "locked/blocked" by the operator, and we get
successive
generic
errors while sending PDUs to the modem.
As this can occur occasionally for working modems, i.e. when
bearerbox
injects
the PDU "too fast" while the modem is still in operation, we needed a
heuristic
to detect that state. As we can't do that on the one time event
error.
We use the privdata->retry variable, that is NOT used by any other
pat of
the
code (why??) to increment the value successively. If we hit the
'max-error-count' threshold in a row, we assume we have a dead SIM
card
and
take
the smsc group down.
Votes for CVS commit and comments please.
Thanks,
Stipe
--
-------------------------------------------------------------------
K?lner Landstrasse 419
40589 D?sseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org <st_%7Bat%7D_tolj.org> mailto:
stolj_{at}_kannel.org <stolj_%7Bat%7D_kannel.org>
-------------------------------------------------------------------
### Eclipse Workspace Patch 1.0
#P gateway-cvs-head
Index: gw/smsc/smsc_at.c
===================================================================
RCS file: /home/cvs/gateway/gw/smsc/smsc_at.c,v
retrieving revision 1.57
diff -u -r1.57 smsc_at.c
--- gw/smsc/smsc_at.c 15 Feb 2009 19:49:26 -0000 1.57
+++ gw/smsc/smsc_at.c 8 Apr 2009 19:42:11 -0000
@@ -1598,6 +1598,7 @@
privdata->pin = cfg_get(cfg, octstr_imm("pin"));
privdata->pin_ready = 0;
privdata->conn = conn;
+ privdata->retry = 0;
privdata->phase2plus = 0;
privdata->validityperiod = cfg_get(cfg,
octstr_imm("validityperiod"));
if (cfg_get_integer((long *) &privdata->max_error_count, cfg,
octstr_imm("max-error-count")) == -1)
@@ -2287,7 +2288,26 @@
if (ret != 0) {
bb_smscconn_send_failed(privdata->conn, msg,
SMSCCONN_FAILED_TEMPORARILY,
octstr_create("ERROR"));
- }else{
+
+ /*
+ * If a SIM card is locked by the GSM operator, we
still
can
+ * send PDUs to the modem, but we will constantly
get
ERROR
+ * as response. If we get this 'max-error-count'
times,
then
+ * we consider this route as NO viable route and
shutdown
the
+ * smsc group.
+ */
+ if (ret == -1) {
+ privdata->retry++;
+ if (privdata->max_error_count > 0 &&
+ privdata->retry > privdata-
>max_error_count) {
+ at2_shutdown_cb(privdata->conn, 0);
+ }
+ }
+
+ } else {
+ /* reset error counter */
+ privdata->retry = 0;
+
/* store DLR message if needed for SMSC generated
delivery
reports */
if (DLR_IS_ENABLED_DEVICE(msg->sms.dlr_mask)) {
if (msg_id == -1)
Index: doc/userguide/userguide.xml
===================================================================
RCS file: /home/cvs/gateway/doc/userguide/userguide.xml,v
retrieving revision 1.345
diff -u -r1.345 userguide.xml
--- doc/userguide/userguide.xml 15 Feb 2009 23:13:55 -0000 1.345
+++ doc/userguide/userguide.xml 8 Apr 2009 19:42:07 -0000
@@ -3708,8 +3708,13 @@
<entry><literal>integer</literal></entry>
<entry valign="bottom">
Maximal error count for opening modem device or
initializing of
the modem before
- <literal>reset-string</literal> will be executed. This is
useful
when modem crashed and needs
- hard reset. Default disabled.
+ <literal>reset-string</literal> will be executed.
+ This is useful when modem crashed and needs hard reset.
Default
disabled.
+ Also used as maximum value for successive generic errors
from
the modem while
+ PDUs are passed. If we hit this thresshold we will
assume that
the SIM card
+ in the modem is not functional anymore, and shutdown the
smsc
group. The
+ HTTP admin status page will show this modem as 'dead' in
the
status. So
+ corresponding system admins and/or monitoring components
can
take action.
</entry></row>
<row><entry><literal>host</literal></entry>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.kannel.org/pipermail/devel/attachments/20090417/f8650e29/attachm
ent-0001.html>
------------------------------
_______________________________________________
devel mailing list
[email protected]
http://www.kannel.org/mailman/listinfo/devel
End of devel Digest, Vol 32, Issue 26
*************************************
