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 *************************************
