It can be just the binary representation of the MAC address in string format, as it is exactly 6 characters:
"~]H'EH"
7e:5d:48:27:45:48 (https://www.rapidtables.com/code/text/ascii-table.html); but it also depends on how your SNMP walk displayed the text. I don't see many people writing their own SNMP management system, so that may be why there are not so many responses.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------
Original Message:
Sent: Feb 13, 2024 01:21 PM
From: bapplegate
Subject: AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses
Going to have a conversation with myself here :). Honestly just posting for posterity in case this would help anyone else...
I bought a basic support contract and opened a TAC case on this. I will update with the results of that when I have them (hopefully a fixed version of code).
Original Message:
Sent: Feb 04, 2024 03:40 PM
From: bapplegate
Subject: AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses
Hello all,
So first off - I don't have support on these. These are used at my house.
I'm running 8.10.0.9 on AP-515s (3 of them).
I have a python script that shows me all connected clients and some details on command line. This started choking the other day on a data type, and I've finally found the culprit. The VC is giving me the wrong data type as well as what looks like garbage output for one particular client. This client is visible in the Web GUI just fine.
It's not the python either, snmpwalk confirms the same thing. Here is the issue (you will see it near the bottom of connected clients. I have sanitized the output a bit:
vom@ice:~$ snmpwalk -v 2c -c public ap-vc 1.3.6.1.4.1.14823.2.3.3.1.2.4.1.1iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.2.90.62.0.0.0 Hex-STRING: 02 5A 3E CA 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.24.62.239.0.0.0 Hex-STRING: 18 3E EF DD 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.24.180.48.0.0.0 Hex-STRING: 18 B4 30 5E 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.24.180.48.0.0.0 Hex-STRING: 18 B4 30 74 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.38.51.151.0.0.0 Hex-STRING: 26 33 97 C4 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.40.207.81.0.0.0 Hex-STRING: 28 CF 51 09 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.60.34.251.0.0.0 Hex-STRING: 3C 22 FB 31 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.60.166.246.0.0.0 Hex-STRING: 3C A6 F6 02 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.68.187.59.0.0.0 Hex-STRING: 44 BB 3B 09 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.68.187.59.0.0.0 Hex-STRING: 44 BB 3B 0A 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.68.187.59.0.0.0 Hex-STRING: 44 BB 3B 0A 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.80.20.121.0.0.0 Hex-STRING: 50 14 79 71 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.100.22.102.0.0.0 Hex-STRING: 64 16 66 3D 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.100.22.102.0.0.0 Hex-STRING: 64 16 66 46 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.100.22.102.0.0.0 Hex-STRING: 64 16 66 48 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.100.82.153.0.0.0 Hex-STRING: 64 52 99 9F 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.122.93.21.0.0.0 Hex-STRING: 7A 5D 15 DB 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.126.93.72.0.0.0 STRING: "~]H'EH"iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.148.234.50.0.0.0 Hex-STRING: 94 EA 32 78 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.156.123.239.0.0.0 Hex-STRING: 9C 7B EF 93 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.158.80.146.0.0.0 Hex-STRING: 9E 50 92 1C 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.184.39.235.0.0.0 Hex-STRING: B8 27 EB 2C 00 00 00iso.3.6.1.4.1.14823.2.3.3.1.2.4.1.1.212.240.87.0.0.0 Hex-STRING: D4 F0 57 7A 00 00 00
So one of the client OIDs comes back as a STRING (should be Hex-STRING) as well as garbage "~]H'EH". Not that it should matter - but this is actually an Apple watch and therefore like all other modern Apple devices - uses a per-network "privacy" MAC. I currently have/had plenty of other Apple devices (including watches) come back just fine from this SNMP OID to get their MAC.
Since I don't have a support contract - I don't believe I can file a bug. Is there anything I can do to get this any attention ?
Thanks.