Controllerless Networks

 View Only
last person joined: yesterday 

Instant Mode - the controllerless Wi-Fi solution that's easy to set up, is loaded with security and smarts, and won't break your budget
Expand all | Collapse all

AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses

This thread has been viewed 36 times
  • 1.  AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses

    Posted Feb 04, 2024 03:40 PM

    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.1
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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 00
    iso.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.



  • 2.  RE: AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses

    Posted Feb 13, 2024 01:21 PM

    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).




  • 3.  RE: AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses

    EMPLOYEE
    Posted Feb 14, 2024 06:20 AM

    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.
    ------------------------------



  • 4.  RE: AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses

    Posted Feb 14, 2024 10:37 AM

    Indeed it is.  I still don't think this is normal behavior from the AP though.  I've been using my script to poll this for years and just recently hit this behavior with this one specific MAC address.  Very strange.  I will wait to see what Aruba TAC says.




  • 5.  RE: AP515s (IAP mode) giving garbage value in SNMP response for connected client MAC addresses

    Posted Feb 16, 2024 08:09 PM

    I don't see "garbage". I see your script fails to recognize String as opposed to Hex String. The output is even telling you it's different and it's telling you how to handle it. I think you need to update your script.