in reply to Net::SNMP get_request() caching results?

i'm not 100% certain that i completely understand the problem that you are seeing, however i've done my share of wrestling with net::snmp. the one bit of advice that i would give you, is that perhaps rather than testing on whether $response is defined, you may want to test on if $error exists. i generally make a seperate call to grab the error return if it exists

my $session = Net::SNMP->session ( ... );
my $error = $session->error;

[download]

perhaps a next if ($error); or just test on $error's existance, rather than checking if $session is defined?

humbly -c

Replies are listed 'Best First'.
Re: Re: Net::SNMP get_request() caching results?
by the_0ne (Pilgrim) on Nov 08, 2001 at 10:46 UTC
    Thanks for the reply c and I understand your confusion. It's not easy to explain without giving the entire code and having a go at it and there's a lot more code than that.

    The whole jist of it is I'm running snmp commands on routers on our network. So, I define a session for a router by it's ip and then I run the snmp commands. (On the same $session that was defined.) So, if I have 4 snmp commands to run on that same ip, I run them in a loop using the same SNMP session that was defined. Well, when I get a response that is an error like not being able to resolve the name or some kind of other error, the error never seems to clear. Even though I set $response as undef, the get_request() seems to not reset for that particular ip on the next go around, until I kill the script and re-run it.

    Thanks again for your reply.
[reply]
      Everything you're saying sounds *really* familiar to me. I've written a utility that runs against routers using net::snmp. The script that is in the code section of the website isnt the most up to date, so I've gone through a few revisions since I posted. The most current one is here. Not sure if it could be of any insight, but I would imagine that I've faced some of your hurdles as well.

      I think I have a bit clearer view of what you're doing now with the loop. Does it just fail for this one remote node? And is the failure the result of the script not being able to resolve the node name to an ip address or is it a timeout general?

      humbly -c

[reply]
        You're exactly right, the error happens on one remote node. So, say node 100 with ip 192.168.1.101 has 10 snmp commands run against it, well if there is one error on all snmp commands, the error will stay. Even though I'm destroying the snmp session and starting a new one, for the node will fail no matter how many commands I have to run.

        Here's the error from the snmp object that I usually receive...

        No response from remote host '192.168.1.101'

        This has happened using a URL or a straight ip like above. So, it doesn't seem to be a timeout, it looks like it *thinks* it can't hit it, when I try telnetting into the router and everything is fine, it just got stuck again. hmmm.....
[reply]
        On a side note, in looking at this utility, it looks pretty cool except that SNMP v3 still isnt completely baked into Net::SNMP and therefore using your utility with SNMP v1 or SNMP v2 would be *very* hazardous, as read/write community strings would be passed in plain-text over the network.
[reply]

In Section Seekers of Perl Wisdom