[Nagiosplug-devel] Bug 691412 revisited
Mike McHenry
mmchenry at frozenwasteland.com
Tue Mar 11 07:13:17 CET 2003
Thanks for revisiting this; I agree that my patch doesn't have complete
error checking but it may offer some ideas for how to resolve the problem
completely. Please let me know if I can be of any assistance in testing any
patch ideas, thanks!
Mike
-----Original Message-----
From: nagiosplug-devel-admin at lists.sourceforge.net
[mailto:nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of Subhendu
Ghosh
Sent: Tuesday, March 11, 2003 9:02 AM
To: Mike McHenry
Cc: nagiosplug-devel at lists.sourceforge.net
Subject: Re: [Nagiosplug-devel] Bug 691412 revisited
Mike
Looking through the code again - you are right in that the data in Cisco
LocIfDescr is not being retrieved.
If you change line 161 and 196 from $snmpIfName to $snmpIfAlias
it should retrieve the correct data.
The mapping is from ifAlias to LocIfDescvr and ifDescr to ifName.
I am up to eliminating the -I switch and having the plugin automatically
figure out whether ifAlias is supported, but the patch in 691412 did not
do any error checking on the get_table to see if the error was related tot
he particular oid.
I opend up 691412 again untill this is resolved.
-sg
On Mon, 10 Mar 2003, Mike McHenry wrote:
> I wanted to revisit a bug I submitted a few weeks ago in the tracking
system
> and give a more in depth description of my experiences with this issue.
> Currently the bug is closed but I think it should be looked at again.
>
> The basic crux of this issue is this: Cisco devices support an SNMP OID
> called LocIfDescr which is basically a local interface descriptor. Most
> other devices do not support this OID and thus this plugin reverts back to
> the IfDescr OID.
>
> Current behavior with the check_ifstatus plugin is to manipulate this
> difference by using the -I flag (as I understand things). The patch I
> submitted in 691412 actually automates this process and allows the
> check_ifstatus plugin to work transparently no matter what device it is
run
> against.
>
> Here is the main reason I am pushing for this patch. There is still a
logic
> bug in the code that can generate errors under certain circumstances. See
> the output below on the stock check_ifstatus plugin run against a Cisco
> device and against a Cabletron device....
>
> CISCO DEVICE
> ============
> # ./check_ifstatus.old -C xx -H switch.example.com
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> CRITICAL: host 'switch.example.com', interfaces up: 9, down: 1, dormant:
> 0<BR>FastEthernet0/24: down -> <BR>
>
> # ./check_ifstatus.old -C xx -H switch.example.com -I
> CRITICAL: host 'switch.example.com', interfaces up: 9, down: 1, dormant:
> 0<BR>FastEthernet0/24: down -> Fa0/24<BR>
>
>
> Running check_ifstatus with -I does not give the LocIfDescr field while
> running check_ifstatus without it generates sprintf errors.
>
>
> CABLETRON DEVICE
> ================
> # ./check_ifstatus.old -C xx -H border.example.com
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> Use of uninitialized value in sprintf at ./check_ifstatus.old line 194.
> CRITICAL: host 'border.example.com', interfaces up: 10, down: 12, dormant:
> 0<BR>Physical port: t3.14.2: down -> <BR>Physical port: t3.14.3: down ->
> <BR>Physical port: t3.16.4: down -> <BR>Physical port: t3.14.4: down ->
> <BR>Physical port: t3.15.1: down -> <BR>Physical port: t3.15.2: down ->
> <BR>Physical port: t3.15.3: down -> <BR>Physical port: t3.14.1: down ->
> <BR>Physical port: t3.15.4: down -> <BR>Physical port: t3.16.1: down ->
> <BR>Physical port: t3.16.2: down -> <BR>Physical port: t3.16.3: down ->
<BR>
>
> Again we get sprintf errors on a non-cisco device.
>
>
> The patch I have included corrects this behavior and should remove the
need
> for the -I flag as I understand it. I have been running this patch on a
> production network for several months no with no abnormal behavior noted.
> This patch has been tested against many different models of Cisco routers
> and switches and also against Cabletron/Riverstone style equipment.
Comments
> are welcome, thanks!
>
> Mike McHenry
> Senior Network Engineer
> ORIGIX Corp.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagiosplug-devel mailing list
> Nagiosplug-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
--
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Nagiosplug-devel mailing list
Nagiosplug-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Devel
mailing list