Hi Hillel,
sorry I don't follow you... Your patch just reverts Stipe patch!
Please submit patch that you think should be applied and we will see
whether you are right...
Thanks,
Alex
P.S. Stipe is not equal Stripe ;)
Am 27.05.2009 um 10:48 schrieb Hillel:
Hi Alex,
To clarify my previous post:
Alex based on your email I was going to send a patch to correct the
user
guide patch sent by Stripe.
(Instead I've attached Stripes patch with a spelling change and added
indentation and hopefully on analysis of the points below it will be
accepted and then so will his code change.)
1. In the first part of the definition of the max-error-count the
user guide
needs to explains the features of the reset-string. Which are that
it is
executed and run by the modem once the max-error-count is reached.
It does
not make sense to change the user guide to write "Maximal error
count for
opening modem device or initializing of the modem before max-error-
count
will be executed."
2. The user guide further on defines the reset-string as the string to
execute when max-error-count is reached. What is written here
explains what
is written further on and so its correct to write it at this point.
3. The second part of the definition of the max-error-count, which
is the
part that Stripe added, only starts from "Also used". From here
onwards the
new features of the max-error-count are explained.
After Stripe's patch is hopefully accepted, we will still need
another patch
to complete this feature and help the developer know why the
connection is
dead (why_killed to be exported via a status call). But nothing can
more
forward until you are happy with the user guide.
Rgds
------------------------------
Date: Sun, 26 Apr 2009 19:22:38 +0200
From: Alexander Malysh <[email protected]>
Subject: Re: [PATCH] SMSC AT - detecting dead SIMs
To: Hillel <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi Hillel,
patch will be accepted if userguide part is fixed.
I would prefer to see why_killed export as extra patch.
Thanks,
Alex
Am 26.04.2009 um 18:48 schrieb Hillel:
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>
------------------------------
<max-error-count-userguide.patch>
