#54 Posible bad values returned for cdp_id and lldp_port with some HP gear



SNMP:Info is a great package; thx for all the work. Found a couple possible bugs/issues using it with HP equipment:

A: Bad value returned for HP cdp_id (and corresponding c_id) when string is a mac address.
B: Possible non-ideal value returned for HP lldp_port (and corresponding c_port) when string is "Port x".

Device being SNMP-polled: HP J8698A Switch E5412zl, revision K.15.07.0008
Neighbor device type 1: HP J8698A Switch E5412zl, revision K.15.07.0008
Neighbor device type 2: ProCurve J9019A Switch 2510-24, revision Q.10.01
Neighbor device type 3: HP AP Controlled, J9650-60001:54-A,

Issue A has been seen with all 3 of the above neighbor device types.
Issue B is only relevant to neighbor device type 3.


$ uname -a
Linux NetDisco 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see perl -V for more detail)

$egrep '^\$VERSION' .../perl5/SNMP/Info.pm
$VERSION = '3.13';

Issue 'A':

An example:
- snmpget for cdpCacheDeviceId gives: Hex-STRING: 00 1B 3F 55 03 00
- snmpget for lldpRemChassisId gives: Hex-STRING: 00 1B 3F 55 03 00
- SNMP::Info::Layer2::HP->lldp_id gives: "00:1b:3f:55:03:00"
- SNMP::Info::Layer2::HP->cdp_id gives: "?U" (as displayed on my screen)

SNMP::Info::Layer2::HP->cdp_id returns the MAC hex-strings in hex, rather than ASCII:
cdp_id returned 0x_E8_39_35_F1_73_B1, rather than "e8:39:35:f1:73:b1"
cdp_id returned 0x_E8_39_35_F1_73_6F, rather than "e8:39:35:f1:73:6f"
cdp_id returned 0x_84_34_97_B6_B8_DA, rather than "84:34:97:b6:b8:da"

Also, some MAC address hex-strings seem to be returned with some bytes missing:
cdp_id returned 0x_FE_AD_60, rather than "00:18:fe:1b:ad:60"
But possibly the missing bytes are due to the code I'm using to convert to hex?
$remote_id_hex = sprintf("0x_%*v2.2X", '_', $remote_id);

Issue 'B':

An example:
- snmpget for cdpCacheDevicePort gives: STRING: "Port 1"
- snmpget for lldpRemPortDesc gives: STRING: "Port 1"
- SNMP::Info::Layer2::HP->cdp_port gives: "Port 1"
- SNMP::Info::Layer2::HP->lldp_port gives: "1"

The string "Port " gets dropped by code (in .../perl5/SNMP/Info/LLDP.pm) that accounts for Avaya/Nortel equipment.

The result of this, for these HP APs at least, is that the LLDP information no longer matches the CDP information, making it harder to recombine. These APs are in "controlled mode", which make them unreachable by SNMP, so I can't comment on the form their ifDescr would otherwise take.


  • Joel Leonhardt

    Joel Leonhardt - 2014-06-03

    For issue A above, where the cdp_id can sometimes be a MAC address, but is then getting treated as control characters, the following patch replaces the default munge_null() call with an attempt to munge_mac() followed by munge_null() only if the munge_mac fails.

    bash> cd .../perl5/SNMP/Info/
    bash> diff CDP.pm.original.v3.13 CDP.pm.patched
    <     'cdp_id'           => 'cdpCacheDeviceId',
    >     'cdp_dev_id'       => 'cdpCacheDeviceId',
    <     'cdp_id'           => \&SNMP::Info::munge_null,
    > sub cdp_id {
    >     my $cdp    = shift;
    >     my $partial = shift;
    >     my $ch = $cdp->cdp_dev_id($partial) || {};
    >     my %cdp_id;
    >     foreach my $key ( sort keys %$ch ) {
    >         my $id = $ch->{$key};
    >         next unless $id;
    >         $id = SNMP::Info::munge_mac($id) || $id;
    >         $id = SNMP::Info::munge_null($id);
    >         $cdp_id{$key} = $id;
    >     }
    >     return \%cdp_id;
    > }
  • Joel Leonhardt

    Joel Leonhardt - 2014-06-03

    Whoops; correction: munge_null is called anyway after munge_mac, but has no effect at that point, unless munge_mac failed to find a MAC address. The two code lines could be combined, if desired, so that munge_null is not called unless munge_mac fails.

    Edit 2014-06-04: Resulting line would be:

    $id = SNMP::Info::munge_mac($id) || SNMP::Info::munge_null($id);
    Last edit: Joel Leonhardt 2014-06-04
  • Eric A. Miller

    Eric A. Miller - 2014-07-02

    Patch for issue A was accepted and applied in this commit.

    Issue B should be resolved by this commit as we now check for the vendor before stripping "Port ".

    Thanks for the patch.

  • Eric A. Miller

    Eric A. Miller - 2014-07-02
    • status: open --> closed
    • assigned_to: Eric A. Miller