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
Description: Binary data
