Re: [tkined] Scotty bug??

fj (Francois.Junique@jet.uk)
Thu, 23 Apr 1998 10:30:52 +0100

--------------FF1BCE827A5E53F64730900D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Radhika Srivatsa wrote:

> Well, I am facing a wierd problem when using scotty to SNMP query a
> router which is unreachable.
> Ideally, I should always get a "noResponse" from this unreachable node.
> But I see that I get a "noError"
> response for an SNMP query made on such an unreachable node. I looked at
> the varbind list associated
> with this node whenever there is a "noError" returned and see that the
> varbind list has some values instead of being NULL.
>
> The error code returned from doing SNMP queries on such an unreachable
> node flaps between "noResponse" and "noError" but on manually checking,
> it is never reachable. Than how come scotty sees it as reachable?
> Hence I wonder if scotty gets confused when it sees a node as
> unreachable for long periods of time that it returns the results of
> another node (which could be the reason that the varbind list is not
> NULL).
>
> Note: I am running my script doing SNMP queries on a lot of nodes
> together using the Asynchronous (Callback) method.
>
> Can anyone please let me know if you have encountered the problem
> outlined above and also the solution if any ?
>
> Thanks!
>
> -Radhika
> Network Management Systems, ANS Communications.
> Voice: (734)214-5970 Fax: (734)214-5934
> radhika@ans.net

Well there used to be a problem! Which was not yet corrected in 2.1.7 , I do
not
know if it is in .8 ?
See the patch from Juergen at that time, below:

Juergen to comment please on the state of this patch in the current/future
version
and version 2. ;-)

------- Start of forwarded message -------
Return-Path: <schoenw@gaertner.de>
Date: Tue, 8 Apr 1997 17:26:21 +0200
From: Juergen Schoenwaelder <schoenw@gaertner.de>
To: Malcom.Bright
Cc: tkined@ibr.cs.tu-bs.de, Francois.Junique
In-Reply-To: <9704041456.AA14933@jet.uk> (Malcom.Bright@jet.uk)
Subject: Re: Problem with scotty

Malcom.Bright@jet.uk said:

Malcom> Unfortunately, when a large proportion of our network is
Malcom> disabled, the request id of one session can catch up with
Malcom> another and thus a reply is posted to a wrong requestor.

Oops, what a stupid bug! I just wrote a small function which generates
unique randomized request ids and hacked to code in tnmSnmpTcl.c to
call this function whenever a request id is needed. This will fix the
problem in the 2.2.0 release. Many thanks for making me aware of this
problem.
Juergen

------- Start of forwarded message -------
Return-Path: <schoenw@gaertner.de>
Date: Fri, 11 Apr 1997 15:35:17 +0200
From: Juergen Schoenwaelder <schoenw@gaertner.de>
To: Malcom.Bright
Cc: tkined@ibr.cs.tu-bs.de, Francois.Junique
In-Reply-To: <9704110907.AA26514@jet.uk> (Malcom.Bright@jet.uk)
Subject: Re: Problem with scotty

Malcom.Bright@jet.uk said:

Malcom> Thanks for your reply. As it was a small routine could you
Malcom> send a copy of it and what changes to call it (no need for a
Malcom> proper patch file). So I may include in our 2.1.5 version.

OK, here is the new function which goes into tnmSnmpUtil.c:

u_int
TnmSnmpGetRequestId()
{
u_int id;
Tnm_SnmpRequest *rPtr = queueHead;

do {
id = rand();
for (rPtr = queueHead; rPtr && rPtr->id != id; rPtr = rPtr->nextPtr)
{
/* empty body */
}
} while (rPtr);

return id;
}

This function should be called at several places in tnmSnmpTcl.c where
you usually find an assignement like:

pdu->request_id = ++session->reqid

This should do the trick. However, you might have to make some
adjustments because I have not tested this with 2.1.5.

Juergen
- --
Juergen Schoenwaelder <schoenw@gaertner.de> (Tel: +49-531-23873-0)
Gaertner Datensysteme, Hamburger Strasse 273a, 38114 Braunschweig, Germany
------- End of forwarded message -------

--
   * * *     mailto:Francois.Junique@jet.uk     Network Co-ordinator
 * Joint *          ext: 4463  blp: 1826        Computer Group
* European*         http://www.jet.uk           CODAS division (J2/A13)
 * Torus *          JET Joint Undertaking       Tel:+44 (01235) 46 4463
   * * *            ABINGDON, OX14 3EA, GB      Fax:+44 (01235) 46 4404

--------------FF1BCE827A5E53F64730900D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Radhika Srivatsa wrote:

Well, I am facing a wierd problem when using scotty to SNMP query a
router which is unreachable.
Ideally, I should always get a "noResponse" from this unreachable node.
But I see that I get a "noError"
response for an SNMP query made on such an unreachable node. I looked at
the varbind list associated
with this node whenever there is a "noError" returned and see that the
varbind list has some values instead of being NULL.

The error code returned from doing SNMP queries on such an unreachable
node flaps between "noResponse" and "noError" but on manually checking,
it is never reachable. Than how come scotty sees it as reachable?
Hence I wonder if scotty gets confused when it sees a node as
unreachable for long periods of time that it returns the results of
another node (which could be the reason that the varbind list is not
NULL).

Note: I am running my script doing SNMP queries on a lot of nodes
together using the Asynchronous (Callback) method.

Can anyone please let me know if you have encountered the problem
outlined above and also the solution if any ?

Thanks!

-Radhika
Network Management Systems, ANS Communications.
Voice: (734)214-5970                     Fax: (734)214-5934
radhika@ans.net

Well there used to be a problem! Which was not yet corrected in 2.1.7 , I do not
know if it is in .8 ?
See the patch from Juergen at that time, below:

Juergen to comment please on the state of this patch in the current/future version
and version 2. ;-)

------- Start of forwarded message -------
Return-Path: <schoenw@gaertner.de>
Date: Tue, 8 Apr 1997 17:26:21 +0200
From: Juergen Schoenwaelder <schoenw@gaertner.de>
To: Malcom.Bright
Cc: tkined@ibr.cs.tu-bs.de, Francois.Junique
In-Reply-To: <9704041456.AA14933@jet.uk> (Malcom.Bright@jet.uk)
Subject: Re: Problem with scotty
 

Malcom.Bright@jet.uk said:

Malcom> Unfortunately, when a large proportion of our network is
Malcom> disabled, the request id of one session can catch up with
Malcom> another and thus a reply is posted to a wrong requestor.

Oops, what a stupid bug! I just wrote a small function which generates
unique randomized request ids and hacked to code in tnmSnmpTcl.c to
call this function whenever a request id is needed. This will fix the
problem in the 2.2.0 release. Many thanks for making me aware of this
problem.
                                                        Juergen

------- Start of forwarded message -------
Return-Path: <schoenw@gaertner.de>
Date: Fri, 11 Apr 1997 15:35:17 +0200
From: Juergen Schoenwaelder <schoenw@gaertner.de>
To: Malcom.Bright
Cc: tkined@ibr.cs.tu-bs.de, Francois.Junique
In-Reply-To: <9704110907.AA26514@jet.uk> (Malcom.Bright@jet.uk)
Subject: Re: Problem with scotty
 

Malcom.Bright@jet.uk said:

Malcom> Thanks for your reply. As it was a small routine could you
Malcom> send a copy of it and what changes to call it (no need for a
Malcom> proper patch file). So I may include in our 2.1.5 version.

OK, here is the new function which goes into tnmSnmpUtil.c:

u_int
TnmSnmpGetRequestId()
{
    u_int id;
    Tnm_SnmpRequest *rPtr = queueHead;

    do {
        id = rand();
        for (rPtr = queueHead; rPtr && rPtr->id != id; rPtr = rPtr->nextPtr) {
            /* empty body */
        }
    } while (rPtr);

    return id;
}

This function should be called at several places in tnmSnmpTcl.c where
you usually find an assignement like:

        pdu->request_id = ++session->reqid

This should do the trick. However, you might have to make some
adjustments because I have not tested this with 2.1.5.

                                                        Juergen
- --
Juergen Schoenwaelder     <schoenw@gaertner.de>     (Tel: +49-531-23873-0)
Gaertner Datensysteme, Hamburger Strasse 273a, 38114 Braunschweig, Germany
------- End of forwarded message -------

-- 
   * * *     mailto:Francois.Junique@jet.uk     Network Co-ordinator
 * Joint *          ext: 4463  blp: 1826        Computer Group
* European*         http://www.jet.uk           CODAS division (J2/A13)
 * Torus *          JET Joint Undertaking       Tel:+44 (01235) 46 4463
   * * *            ABINGDON, OX14 3EA, GB      Fax:+44 (01235) 46 4404
  --------------FF1BCE827A5E53F64730900D-- -- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.