Hi Alex,

>From your email below it seems you wanted in the user guide's patch the
reset-string to be changed to max-error-count.
If so then please explain the user guide's definition of reset-string "Which
reset string to execute when max-error-count reached. Example for Falcom:
AT+CFUN=1" does not make sense.
Also it does not make sense to say max-error-count is executed as the
reset-string, if it's used, is sent to the modem.
If so Stripe is correct and his user guide patch should be fine (besides the
word thresshold changed to threshold) and his code accepted to CVS. 
I was going to send a patch to fix the user guide  - if it is actually
incorrect. :)

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



Reply via email to