[prev in list] [next in list] [prev in thread] [next in thread]
List: net-snmp-patches
Subject: [Net-snmp-patches] [ net-snmp-Patches-2952708 ] implementation of
From: "SourceForge.net" <noreply () sourceforge ! net>
Date: 2010-03-31 15:34:56
Message-ID: E1NwzwW-0004Dm-KY () sfs-web-11 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]
Patches item #2952708, was opened at 2010-02-16 12:18
Message generated for change (Settings changed) made by jsafranek
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=2952708&group_id=12694
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jens Osterkamp (jenso)
Assigned to: Jan Safranek (jsafranek)
Summary: implementation of bridge mib as perl module v2
Initial Comment:
we have started to implement the brige mib (RFC 4188) as a perl module.
Currently implemented are
- dot1dBasePort
- dot1dBasePortIfIndex
- dot1dTpFdbAddress
- dot1dTpFdbPort
- dot1dTpFdbStatus
We are planning to extend it piece by piece.
One of the limitations that we have identified so far is that the bridge mib
only represents one but not multiple bridge instances.
Under Linux, the module can be installed by adding
perl do "/etc/snmp/bridge.pl"
to /etc/snmp/snmpd.conf or (alternatively) run as a "standalone"
perl module which attaches to snmpd via agentx:
perl ./bridge.pl
Any comments and suggestions are highly appreciated !
Tested under Linux on an x86 box with net-snmp 5.4.2.1 on Fedora 12
----------------------------------------------------------------------
Comment By: Jan Safranek (jsafranek)
Date: 2010-03-31 17:34
Message:
SVN rev. 18414.
----------------------------------------------------------------------
Comment By: Jan Safranek (jsafranek)
Date: 2010-03-31 17:34
Message:
Thanks for the patch! It has been applied to the current
development code, and will appear in the next major release
of the Net-SNMP package.
----------------------------------------------------------------------
Comment By: Jens Osterkamp (jenso)
Date: 2010-03-31 14:03
Message:
Attached new version v7 and a man page as requested.
----------------------------------------------------------------------
Comment By: Jens Osterkamp (jenso)
Date: 2010-03-23 15:15
Message:
> It just prints now at the end of snmpwalk following garbage:
> type not defined !
> value not defined !
>
> Looking at the code, this seems to be expected behaviour. IMHO only real
> errors should go to stderr though.
Removed. I am planning to implement some more proper logging for debug
purposes later.
> I use Fedora rawhide with net-snmp-5.5, the perl script is working as
> AgentX subagent.
> However, the bug seems to be gone, snmpwalk returns the same results all
> the time, with or without sleep between.
As I mentioned I have never seen this here, but I have a machine with
rawhide now which I can test on.
> I still see wrong MAC address, even in the first snmpwalk:
> BRIDGE-MIB::dot1dBaseBridgeAddress = STRING:
> 37:36:3a:33:34:3a:61:35:3a:63:33:3a:66:63:3a:65:61
>
> My bridge:
> br0 Link encap:Ethernet HWaddr 76:34:A5:C3:FC:EA
>
> Looking at the code, it seems there is missing mac2hex() around
> readfile():
> print STDERR "determining bridge address.\n";
>
> $oid=".1.3.6.1.2.1.17.1.1";
> $oid_value{$oid}=readfile($netdir."br0/address", 0);
I put in the mac2hex which you suggested. I see no difference, so could
you please test if this fixes it ?
> It's still the same,
> BRIDGE-MIB::dot1dTpFdbAddress.'v4....' = STRING: 76:34:a5:c3:fc:ea
> BRIDGE-MIB::dot1dTpFdbAddress.'zL.V.X' = STRING: 7a:4c:b5:56:f0:58
> BRIDGE-MIB::dot1dTpFdbPort.'v4....' = INTEGER: 1
> BRIDGE-MIB::dot1dTpFdbPort.'zL.V.X' = INTEGER: 1
fixed. will attach v5 soon.
----------------------------------------------------------------------
Comment By: Jan Safranek (jsafranek)
Date: 2010-03-18 16:13
Message:
Testing v4:
1),3), 6) is indeed fixed, no warnings this time
It just prints now at the end of snmpwalk following garbage:
type not defined !
value not defined !
Looking at the code, this seems to be expected behaviour. IMHO only real
errors should go to stderr though.
>> 7) What troubles me most is the fact that if I run snmpwalk twice
after
>> longer time I get different output:
>[...]
>> If I do two walks without any sleep between, I get correct results.
>
>Very strange. I do not see this here. Seems to be a problem in
>repopulation of the bridge mib after the 60 second cache timeout.
>
>What is your test environment and how do you invoke the script ?
embedded
>or agent-x ?
I use Fedora rawhide with net-snmp-5.5, the perl script is working as
AgentX subagent.
However, the bug seems to be gone, snmpwalk returns the same results all
the time, with or without sleep between.
>> 8) dot1dBaseBridgeAddress has strange value - see the walks above. IMHO
it
>> should be MAC, i.e. 6 bytes, not 17.
>
>Same as above...maybe something with incorrect repopulation of data
>structures.
I still see wrong MAC address, even in the first snmpwalk:
BRIDGE-MIB::dot1dBaseBridgeAddress = STRING:
37:36:3a:33:34:3a:61:35:3a:63:33:3a:66:63:3a:65:61
My bridge:
br0 Link encap:Ethernet HWaddr 76:34:A5:C3:FC:EA
Looking at the code, it seems there is missing mac2hex() around
readfile():
print STDERR "determining bridge address.\n";
$oid=".1.3.6.1.2.1.17.1.1";
$oid_value{$oid}=readfile($netdir."br0/address", 0);
>> 9) I am not sure if dot1dBaseNumPorts or dot1dBasePortTable is
correct...
> I think it is correct, but will check back.
Fine then.
>> 10) dot1dTpFdbPort is maybe wrong, IMHO one of them should be '2' -
tap0
>> and tap1 have different port in dot1dBasePortTable.
>> BRIDGE-MIB::dot1dTpFdbAddress.'.....d' = STRING: ca:82:ee:ff:fb:64
>> BRIDGE-MIB::dot1dTpFdbAddress.'.x..c.' = STRING: fe:78:c:f0:63:cf
>> BRIDGE-MIB::dot1dTpFdbPort.'.....d' = INTEGER: 1
>> BRIDGE-MIB::dot1dTpFdbPort.'.x..c.' = INTEGER: 1
>
> yep, looks wrong, will look again.
It's still the same,
BRIDGE-MIB::dot1dTpFdbAddress.'v4....' = STRING: 76:34:a5:c3:fc:ea
BRIDGE-MIB::dot1dTpFdbAddress.'zL.V.X' = STRING: 7a:4c:b5:56:f0:58
BRIDGE-MIB::dot1dTpFdbPort.'v4....' = INTEGER: 1
BRIDGE-MIB::dot1dTpFdbPort.'zL.V.X' = INTEGER: 1
So, just look at the 1. (stderr) and 10. and that seems to be it!
----------------------------------------------------------------------
Comment By: Jens Osterkamp (jenso)
Date: 2010-03-17 15:01
Message:
Hi Jan,
thanks for testing v3 !
> 1) there are still some Perl warnings, now I *have* an interface in the
> bridge (marked with >>>)
All of these are fixed except the one with the $bridge. This will need a
bit more thinking on how multiple bridges can be handled.
> >>> Argument "STP_PROP_VALUE" isn't numeric in bitwise and (&) at
> /mnt/home/download/bridge.pl line 443, <FILE> line 7.
> >>> Argument "STP_PROP_VALUE" isn't numeric in bitwise and (&) at
> /mnt/home/download/bridge.pl line 440, <FILE> line 7.
> determining MAC addresses.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> >>> Character in 'c' format wrapped in pack at
> /mnt/home/download/bridge.pl line 536, <FILE> line 19.
> finished populating MIB.
> processing get_next for mib-2.17 (.1.3.6.1.2.1.17).
All of these are fixed in the next release.
> processing get_next for mib-2.17.4.3.1.3.202.130.238.255.251.100
> (.1.3.6.1.2.1.17.4.3.1.3.202.130.238.255.251.100).
> processing get_next for mib-2.17.4.3.1.3.254.120.12.240.99.207
> (.1.3.6.1.2.1.17.4.3.1.3.254.120.12.240.99.207).
> >>> Use of uninitialized value $type in concatenation (.) or string at
> /mnt/home/download/bridge.pl line 131, <FILE> line 19.
> >>> Use of uninitialized value $value in concatenation (.) or string at
> /mnt/home/download/bridge.pl line 131, <FILE> line 19.
> >>> oid(0) or type() or value() not defined !
fixed.
> 2) the mysterious error seems to be gone in net-snmp-5.5
weird. With 5.4.2.1 I can still see it. Maybe it was a net-snmp bug.
> 3) the 'c' format error is still there, see above
fixed.
> 6) snmpwalk -v2c -c public localhost .1.3.6.1.2.1.17 complains about
some
> types:
> BRIDGE-MIB::dot1dStpTimeSinceTopologyChange = Wrong Type (should be
> Timeticks): INTEGER: 0
> BRIDGE-MIB::dot1dStpTopChanges = Wrong Type (should be Counter32):
> INTEGER: 0
fixed.
> 7) What troubles me most is the fact that if I run snmpwalk twice after
> longer time I get different output:
[...]
> If I do two walks without any sleep between, I get correct results.
Very strange. I do not see this here. Seems to be a problem in
repopulation of the bridge mib after the 60 second cache timeout.
What is your test environment and how do you invoke the script ? embedded
or agent-x ?
I am using F12 with net-snmp 5.4.2.1 as shipped with F12.
> 8) dot1dBaseBridgeAddress has strange value - see the walks above. IMHO
it
> should be MAC, i.e. 6 bytes, not 17.
Same as above...maybe something with incorrect repopulation of data
structures.
> 9) I am not sure if dot1dBaseNumPorts or dot1dBasePortTable is
correct...
> BRIDGE-MIB::dot1dBaseNumPorts = INTEGER: 2 ports
> Ok, I have two ports (tap0 and tap1) in the bridge. So, why do I have
> three entries in the table?
> BRIDGE-MIB::dot1dBasePort.1 = INTEGER: 1
> BRIDGE-MIB::dot1dBasePort.2 = INTEGER: 2
> BRIDGE-MIB::dot1dBasePort.3 = INTEGER: 3
>
> Looking at the dot1dBasePortIfIndex, it seems that the bridge itself
(br0)
> is in the table. Is it correct? I admit I don't understand the
description
> in RFC ('Transparent, source-route, and srt ports are included.'). Is
the
> bridge itself source-route? Or srt port?
I think it is correct, but will check back.
> 10) dot1dTpFdbPort is maybe wrong, IMHO one of them should be '2' -
tap0
> and tap1 have different port in dot1dBasePortTable.
> BRIDGE-MIB::dot1dTpFdbAddress.'.....d' = STRING: ca:82:ee:ff:fb:64
> BRIDGE-MIB::dot1dTpFdbAddress.'.x..c.' = STRING: fe:78:c:f0:63:cf
> BRIDGE-MIB::dot1dTpFdbPort.'.....d' = INTEGER: 1
> BRIDGE-MIB::dot1dTpFdbPort.'.x..c.' = INTEGER: 1
yep, looks wrong, will look again.
----------------------------------------------------------------------
Comment By: Jan Safranek (jsafranek)
Date: 2010-03-05 11:12
Message:
Testing the v3 version with following setup:
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.ca82eefffb64 no tap0
tap1
$ ifconfig
br0 Link encap:Ethernet HWaddr CA:82:EE:FF:FB:64
tap0 Link encap:Ethernet HWaddr FE:78:0C:F0:63:CF
tap1 Link encap:Ethernet HWaddr CA:82:EE:FF:FB:64
In general it looks better than before and I appreciate lot of new
dot1dStp stuff.
1) there are still some Perl warnings, now I *have* an interface in the
bridge (marked with >>>)
On startup:
>>> Useless use of a variable in void context at
/mnt/home/download/bridge.pl line 164.
>>> Useless use of a variable in void context at
/mnt/home/download/bridge.pl line 164.
>>> Useless use of a variable in void context at
/mnt/home/download/bridge.pl line 164.
>>> Useless use of a variable in void context at
/mnt/home/download/bridge.pl line 164.
>>> Name "main::bridge" used only once: possible typo at
/mnt/home/download/bridge.pl line 194.
>>> Name "main::PRT" used only once: possible typo at
/mnt/home/download/bridge.pl line 508.
On walk through whole 1.3.6.1.2.1.17 tree:
populating MIB
identifying bridges:
br0
determining bridge address.
determining number of ports.
found interface br0 - tap0
found interface br0 - tap1
determining base type.
identifying interfaces and forward db.
determining baseports.
determining STP properties.
>>> Argument "STP_PROP_VALUE" isn't numeric in bitwise and (&) at
/mnt/home/download/bridge.pl line 443, <FILE> line 7.
>>> Argument "STP_PROP_VALUE" isn't numeric in bitwise and (&) at
/mnt/home/download/bridge.pl line 440, <FILE> line 7.
determining MAC addresses.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
>>> Character in 'c' format wrapped in pack at
/mnt/home/download/bridge.pl line 536, <FILE> line 19.
finished populating MIB.
processing get_next for mib-2.17 (.1.3.6.1.2.1.17).
...
processing get_next for mib-2.17.4.3.1.3.202.130.238.255.251.100
(.1.3.6.1.2.1.17.4.3.1.3.202.130.238.255.251.100).
processing get_next for mib-2.17.4.3.1.3.254.120.12.240.99.207
(.1.3.6.1.2.1.17.4.3.1.3.254.120.12.240.99.207).
>>> Use of uninitialized value $type in concatenation (.) or string at
/mnt/home/download/bridge.pl line 131, <FILE> line 19.
>>> Use of uninitialized value $value in concatenation (.) or string at
/mnt/home/download/bridge.pl line 131, <FILE> line 19.
>>> oid(0) or type() or value() not defined !
2) the mysterious error seems to be gone in net-snmp-5.5
3) the 'c' format error is still there, see above
4) snmpwalk works better, but see below...
There are some new problems:
6) snmpwalk -v2c -c public localhost .1.3.6.1.2.1.17 complains about some
types:
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange = Wrong Type (should be
Timeticks): INTEGER: 0
BRIDGE-MIB::dot1dStpTopChanges = Wrong Type (should be Counter32):
INTEGER: 0
7) What troubles me most is the fact that if I run snmpwalk twice after
longer time I get different output:
$ snmpwalk localhost .1.3.6.1.2.1.17; sleep 60; snmpwalk localhost
.1.3.6.1.2.1.17
BRIDGE-MIB::dot1dBaseBridgeAddress = STRING:
63:61:3a:38:32:3a:65:65:3a:66:66:3a:66:62:3a:36:34
BRIDGE-MIB::dot1dBaseNumPorts = INTEGER: 2 ports
BRIDGE-MIB::dot1dBaseType = INTEGER: transparent-only(2)
BRIDGE-MIB::dot1dBasePort.1 = INTEGER: 1
BRIDGE-MIB::dot1dBasePort.2 = INTEGER: 2
BRIDGE-MIB::dot1dBasePort.3 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.1 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.2 = INTEGER: 5
BRIDGE-MIB::dot1dBasePortIfIndex.3 = INTEGER: 4
BRIDGE-MIB::dot1dStpProtocolSpecification = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority = INTEGER: 32768
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange = Wrong Type (should be
Timeticks): INTEGER: 0
BRIDGE-MIB::dot1dStpTopChanges = Wrong Type (should be Counter32):
INTEGER: 0
BRIDGE-MIB::dot1dStpDesignatedRoot = STRING: "8000.ca82eefffb64"
BRIDGE-MIB::dot1dStpRootCost = INTEGER: 0
BRIDGE-MIB::dot1dStpRootPort = INTEGER: 0
BRIDGE-MIB::dot1dStpMaxAge = INTEGER: 1999 centi-seconds
BRIDGE-MIB::dot1dStpHelloTime = INTEGER: 199 centi-seconds
BRIDGE-MIB::dot1dStpForwardDelay = INTEGER: 1499 centi-seconds
BRIDGE-MIB::dot1dStpBridgeMaxAge = INTEGER: 1999 centi-seconds
BRIDGE-MIB::dot1dStpBridgeHelloTime = INTEGER: 199 centi-seconds
BRIDGE-MIB::dot1dStpBridgeForwardDelay = INTEGER: 1499 centi-seconds
BRIDGE-MIB::dot1dTpFdbAddress.'.....d' = STRING: ca:82:ee:ff:fb:64
BRIDGE-MIB::dot1dTpFdbAddress.'.x..c.' = STRING: fe:78:c:f0:63:cf
BRIDGE-MIB::dot1dTpFdbPort.'.....d' = INTEGER: 1
BRIDGE-MIB::dot1dTpFdbPort.'.x..c.' = INTEGER: 1
BRIDGE-MIB::dot1dTpFdbStatus.'.....d' = INTEGER: self(4)
BRIDGE-MIB::dot1dTpFdbStatus.'.x..c.' = INTEGER: self(4)
^ first walk ^
< 60 seconds of idle here >
v second valk v
BRIDGE-MIB::dot1dBaseBridgeAddress = STRING:
63:61:3a:38:32:3a:65:65:3a:66:66:3a:66:62:3a:36:34
BRIDGE-MIB::dot1dBaseNumPorts = INTEGER: 4 ports
BRIDGE-MIB::dot1dBaseType = INTEGER: transparent-only(2)
BRIDGE-MIB::dot1dBasePort.1 = INTEGER: 1
BRIDGE-MIB::dot1dBasePort.2 = INTEGER: 2
BRIDGE-MIB::dot1dBasePort.3 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.1 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.2 = INTEGER: 5
BRIDGE-MIB::dot1dBasePortIfIndex.3 = INTEGER: 4
I miss dot1dStp and dot1dTpFdb completely... And the second walk shows
that I have 4 ports in the bridge, which I don't have. Relevant bridge.pl
output (second walk):
populating MIB
identifying bridges:
br0
determining bridge address.
determining number of ports.
found interface br0 - tap0
found interface br0 - tap1
found interface br0 - tap0
found interface br0 - tap1
determining base type.
...
If I do two walks without any sleep between, I get correct results.
8) dot1dBaseBridgeAddress has strange value - see the walks above. IMHO it
should be MAC, i.e. 6 bytes, not 17.
9) I am not sure if dot1dBaseNumPorts or dot1dBasePortTable is correct...
BRIDGE-MIB::dot1dBaseNumPorts = INTEGER: 2 ports
Ok, I have two ports (tap0 and tap1) in the bridge. So, why do I have
three entries in the table?
BRIDGE-MIB::dot1dBasePort.1 = INTEGER: 1
BRIDGE-MIB::dot1dBasePort.2 = INTEGER: 2
BRIDGE-MIB::dot1dBasePort.3 = INTEGER: 3
Looking at the dot1dBasePortIfIndex, it seems that the bridge itself (br0)
is in the table. Is it correct? I admit I don't understand the description
in RFC ('Transparent, source-route, and srt ports are included.'). Is the
bridge itself source-route? Or srt port?
10) dot1dTpFdbPort is maybe wrong, IMHO one of them should be '2' - tap0
and tap1 have different port in dot1dBasePortTable.
BRIDGE-MIB::dot1dTpFdbAddress.'.....d' = STRING: ca:82:ee:ff:fb:64
BRIDGE-MIB::dot1dTpFdbAddress.'.x..c.' = STRING: fe:78:c:f0:63:cf
BRIDGE-MIB::dot1dTpFdbPort.'.....d' = INTEGER: 1
BRIDGE-MIB::dot1dTpFdbPort.'.x..c.' = INTEGER: 1
----------------------------------------------------------------------
Comment By: Jens Osterkamp (jenso)
Date: 2010-03-04 15:29
Message:
Hello Jan,
thank you for testing this !
> 1. If there is bridge with no interfaces (just 'brctl addbr br0'), perl
-w
> shows lot of warnings:
[...]
> Some checks that there is at least one interface in the bridge would
> probably help a bit.
You are absolutely right, I also came across this. I already created a new
version of the script which (amongst other things) fixes this.
> 2. There is one mysterious error, probably at bridge.pl:262 :
> Argument "mib-2.17.1.4.1" isn't numeric in subroutine entry at
>
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/NetSNMP/OID.pm
> line 152.
> It can be bug in Net-SNMP not in your code though.
Andrej Shalaev and also me came across this. I tried to debug it, but
never really found a cause.
I think I will ask on net-snmp-coders about this.
> 3. With mac '2e:8b:58:a1:fd:98' this error shows up 4x:
> Character in 'c' format wrapped in pack at bridge.pl line 339.
> You probably want to use 'C' instead of 'c'.
I will try with this (bridge) MAC. I have not yet seen problems with the
MAC adresses generated on my system though.
> 4. With simple bridge snmpwalk shows following output:
[...]
> 'mib-2.17.1.4.1.2.3' => 0 <--- ERROR HERE
The problem is that next oid is dynamically created based on the mac
address of the first interface in this bridge.
It is fixed in the next version of the script.
> 5. If I walk through dot1dTpFdbTable, I get some ugly output:
> BRIDGE-MIB::dot1dTpFdbAddress.'.L2.^g' = STRING: 2:4c:32:1:5e:67
> BRIDGE-MIB::dot1dTpFdbAddress.'.."%be' = STRING: a2:e4:22:25:62:65
> BRIDGE-MIB::dot1dTpFdbPort.'.L2.^g' = INTEGER: 2
> BRIDGE-MIB::dot1dTpFdbPort.'.."%be' = INTEGER: 2
> BRIDGE-MIB::dot1dTpFdbStatus.'.L2.^g' = INTEGER: self(4)
> BRIDGE-MIB::dot1dTpFdbStatus.'.."%be' = INTEGER: self(4)
>
> But that's probably problem of snmpwalk not being able to convert MAC
> address in the index to nice human-readable format...
Hmm, this indeed looks like snmpwalk is trying to print the mac address in
the OID.
I will discuss to see what I can do about it.
----------------------------------------------------------------------
Comment By: Jan Safranek (jsafranek)
Date: 2010-03-04 12:38
Message:
My perl knowledge is very limited, but I've given it a short test and I've
found:
1. If there is bridge with no interfaces (just 'brctl addbr br0'), perl -w
shows lot of warnings:
Use of uninitialized value $first_baseport in concatenation (.) or string
at bridge.pl line 263.
Use of uninitialized value $prv_baseport in concatenation (.) or string
at bridge.pl line 263.
Use of uninitialized value $prv_baseport in concatenation (.) or string
at bridge.pl line 264.
Use of uninitialized value $first_mac_oid in concatenation (.) or string
at bridge.pl line 308.
Use of uninitialized value $prv_mac_oid in concatenation (.) or string at
bridge.pl line 308.
Use of uninitialized value $first_mac_oid in concatenation (.) or string
at bridge.pl line 309.
Use of uninitialized value $prv_mac_oid in concatenation (.) or string at
bridge.pl line 309.
Use of uninitialized value $prv_mac_oid in concatenation (.) or string at
bridge.pl line 310.
Some checks that there is at least one interface in the bridge would
probably help a bit.
2. There is one mysterious error, probably at bridge.pl:262 :
Argument "mib-2.17.1.4.1" isn't numeric in subroutine entry at
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/NetSNMP/OID.pm
line 152.
It can be bug in Net-SNMP not in your code though.
3. With mac '2e:8b:58:a1:fd:98' this error shows up 4x:
Character in 'c' format wrapped in pack at bridge.pl line 339.
You probably want to use 'C' instead of 'c'.
4. With simple bridge snmpwalk shows following output:
$ brctl addbr br0
$ tunctl
$ tunctl
$ brctl addif br0 tap0
$ brctl addif br0 tap1
$ snmpwalk localhost 1.3.6.1.2.1.17
BRIDGE-MIB::dot1dBasePort.1 = INTEGER: 1
BRIDGE-MIB::dot1dBasePort.2 = INTEGER: 2
BRIDGE-MIB::dot1dBasePort.3 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.1 = INTEGER: 8
BRIDGE-MIB::dot1dBasePortIfIndex.2 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.3 = INTEGER: 9
The dot1dBase looks OK, but where is dot1dTpFdbTable? I think you have
messed up %oid_next. If I dump it, I get:
'mib-2.17.1.4.1.1' => 'mib-2.17.1.4.1.1.1'
'mib-2.17.1.4.1.1.1' => 'mib-2.17.1.4.1.1.2'
'mib-2.17.1.4.1.1.2' => 'mib-2.17.1.4.1.1.3'
'mib-2.17.1.4.1.1.3' => 'mib-2.17.1.4.1.2.1'
'mib-2.17.1.4.1.2' => 'mib-2.17.1.4.1.2.1'
'mib-2.17.1.4.1.2.1' => 'mib-2.17.1.4.1.2.2'
'mib-2.17.1.4.1.2.2' => 'mib-2.17.1.4.1.2.3'
'mib-2.17.1.4.1.2.3' => 0 <--- ERROR HERE
'mib-2.17.4.3.1.1' => 'mib-2.17.4.3.1.1.2.76.50.1.94.103'
'mib-2.17.4.3.1.1.162.228.34.37.98.101' =>
'mib-2.17.4.3.1.2.2.76.50.1.94.103'
'mib-2.17.4.3.1.1.2.76.50.1.94.103' =>
'mib-2.17.4.3.1.1.162.228.34.37.98.101'
'mib-2.17.4.3.1.2' => 'mib-2.17.4.3.1.2.2.76.50.1.94.103'
'mib-2.17.4.3.1.2.162.228.34.37.98.101' =>
'mib-2.17.4.3.1.3.2.76.50.1.94.103'
'mib-2.17.4.3.1.2.2.76.50.1.94.103' =>
'mib-2.17.4.3.1.2.162.228.34.37.98.101'
'mib-2.17.4.3.1.3' => 'mib-2.17.4.3.1.3.2.76.50.1.94.103'
'mib-2.17.4.3.1.3.162.228.34.37.98.101' => 0
'mib-2.17.4.3.1.3.2.76.50.1.94.103' =>
'mib-2.17.4.3.1.3.162.228.34.37.98.101'
Next entry of mib-2.17.1.4.1.2.3 should be mib-2.17.4.3.1.1, not zero.
5. If I walk through dot1dTpFdbTable, I get some ugly output:
BRIDGE-MIB::dot1dTpFdbAddress.'.L2.^g' = STRING: 2:4c:32:1:5e:67
BRIDGE-MIB::dot1dTpFdbAddress.'.."%be' = STRING: a2:e4:22:25:62:65
BRIDGE-MIB::dot1dTpFdbPort.'.L2.^g' = INTEGER: 2
BRIDGE-MIB::dot1dTpFdbPort.'.."%be' = INTEGER: 2
BRIDGE-MIB::dot1dTpFdbStatus.'.L2.^g' = INTEGER: self(4)
BRIDGE-MIB::dot1dTpFdbStatus.'.."%be' = INTEGER: self(4)
But that's probably problem of snmpwalk not being able to convert MAC
address in the index to nice human-readable format...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=2952708&group_id=12694
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-patches mailing list
Net-snmp-patches@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-patches
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic