[Nagiosplug-devel] Bug 691412 revisited

[Mike McHenry]

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