RE: snmpget and snmpwalk return corrupt string instead of hex string when MAC address starts with non zero

Randall C Grimshaw <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <D1ED659D5D76664389FB55EE3E3EE506095CE8EF71@suex07-mbx-01.ad.syr.edu>
Fulko:



  Your assistance is greatly appreciated.



  I apologize for making you want to don the lawyers hat, that was not my intention. But could you find your technicians hat for a moment.



  I am able to reproduce the effect by spoofing different MAC addresses. There are a number of devices on our network with A4, The new Dells start with B8, at the moment I am using the spoofed mac of badbadbadbad. So although there should not be any magic associated with the MAC address content, the effect is there.



  I am able to get a correct display using the -Ox parameter. This also shows the correct MAC so that it is an easy comparison between which MACs are and are not displaying correctly without the option. It works consistently as long as the first octet is 00.



  But I am not able to find a way to make the -Ox parameter translate into a config setting or DISPLAY-HINT so that the snmp calls made through the library by PHP work correctly. (I have tried the php tricks like snmp_set_valueretrieval(0)).



  I compiled with --enable-old-features --enable-ucd-snmp-compatibility --with-PACKAGE=ucd_snmp which may be my mistake.



  Can you suggest what might be causing these MAC to display badly? Or perhaps how to add a DISPLAY-HINT to the RFC1213-MIB for ipNetToMediaPhysAddress? Or perhaps ... ???





# /usr/local/src/net-snmp-5.5/apps/snmpwalk -c community routername ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.80

RFC1213-MIB::ipNetToMediaPhysAddress.80.x.x.x.3 = Hex-STRING: 00 11 22 33 44 33

RFC1213-MIB::ipNetToMediaPhysAddress.80.x.x.x.4 = Hex-STRING: 00 11 22 33 44 44

RFC1213-MIB::ipNetToMediaPhysAddress.80.x.x.x.5 = STRING: "¤ºÛô«X"              (this new Dell MAC is known to begin with b8) (non 00)

RFC1213-MIB::ipNetToMediaPhysAddress.80.x.x.x.6 = Hex-STRING: 00 11 22 33 44 66

RFC1213-MIB::ipNetToMediaPhysAddress.80.x.x.x.7 = Hex-STRING: 00 11 22 33 44 77


From: Fulko Hew [mailto:[email protected]]
Sent: Wednesday, July 14, 2010 11:11 AM
To: Randall C Grimshaw
Cc: [email protected]
Subject: Re: snmpget and snmpwalk return corrupt string instead of hex string when MAC address starts with non zero


On Tue, Jul 13, 2010 at 3:15 PM, Randall C Grimshaw <[email protected]<mailto:[email protected]>> wrote:
No luck in forcing the IP-MIB.
I guess I do not understand the DISPLAY-HINT association. The type is clearly defined in the MIB files and do not know why it would not be considered a bug that a MAC address that does not start with 00:xx:xx does not display properly.

Putting on my 'lawyer' hat while reading and interpreting specifications...

The MIB (aka 'the specification') declares the variable as an 'OCTET STRING'.
That means it is "a string of 8 bit quantities that contains 'something'".
That 'something' could be anywhere from a human readable printable string in English
all the way to 'binary crap'.  It is the (informal) DISPLAY-HINT that, if used, allows that
OCTET STRING to be (optionally aka 'hint') interpreted and displayed in a more
intuitive/human manner.
(ie. the 6 bytes are intended to represent a 'MAC address' and could/should be
displayed in the form 'xx:xx:xx:xx:xx:xx'.)

BTW.  I don't think there is anything 'magic' about the first octet in a MAC address.

Fulko

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.