Wireless Access

 View Only
last person joined: 11 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Random clients not getting DHCP address

This thread has been viewed 52 times
  • 1.  Random clients not getting DHCP address

    Posted Apr 17, 2024 12:36 PM

    Hello all,

    We are running 8.10.0.10.

    I have a few devices,  Macbooks/Windows laptops that pass authentication but wont get DHCP.

    These devices work with other non-Aruba wireless but not sure why DHCP fails when connecting to Aruba.

    So far, the issue looks isolated since we have thousands other clients that work just fine.

    I tried 'sudo ifconfig en0 ether <random mac>' on Macbook but failed so I couldnt verify if issue is tied to specific Mac address.

    Anyone else seen this or have a workaround? 

    Thanks,

    Alex



  • 2.  RE: Random clients not getting DHCP address

    Posted 29 days ago

    We are seeing more clients with DHCP issue.  Devices are able to associate and authenticate but will not get an IP address.

    (wcFIDF3) #show log all | include 6c:1e:d5
    Apr 24 10:44:45 2024  stm[7292]:  <501093> <NOTI> |AP apLB2171@10.2.114.40 stm|  Auth success: d8:9c:67:6c:1e:d5: AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171
    Apr 24 10:44:45 2024  stm[7292]:  <501095> <NOTI> |AP apLB2171@10.2.114.40 stm|  Assoc request @ 10:44:45.069986: d8:9c:67:6c:1e:d5 (SN 0): AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171
    Apr 24 10:44:45 2024  stm[3758]: <501100> <3758> <NOTI> |stm|  Assoc success @ 10:44:45.084913: d8:9c:67:6c:1e:d5: AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171
    Apr 24 10:44:45 2024  authmgr[3736]: <522295> <5326> <DBUG> |authmgr|  Auth GSM : USER_STA event 0 for user d8:9c:67:6c:1e:d5
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  Handling STA UP for d8:9c:67:6c:1e:d5
    Apr 24 10:44:45 2024  authmgr[3736]: <522035> <5326> <INFO> |authmgr|  MAC=d8:9c:67:6c:1e:d5 Station UP: BSSID=68:28:cf:cc:96:80 ESSID=HousePublic VLAN=132 AP-name=apLB2171 u-encr-alg=0x20 m-encr-alg=0x20 at 10:44:44.273576
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  auth_cluster_is_active_uac_or_disconnected: essid HousePublic b_num 167 mac d8:9c:67:6c:1e:d5 
    Apr 24 10:44:45 2024  authmgr[3736]: <522077> <5326> <DBUG> |authmgr|  MAC=d8:9c:67:6c:1e:d5 ingress 0x102be (tunnel 702), u_encr 0x20, m_encr 0x20, slotport 0x2100 , type: local, FW mode: 0, AP IP: 10.2.114.40 mdie 0 ft_complete 0
    Apr 24 10:44:45 2024  authmgr[3736]: <522264> <5326> <DBUG> |authmgr|  "MAC:d8:9c:67:6c:1e:d5: Allocating UUID: 204c030290a00000003149dd
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  ac_active_add_mac_to_bucket: station d8:9c:67:6c:1e:d5 in essid HousePublic (mac_user 0x4ae09ac) being added to bucket-map
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  auth_cluster_add_active_mac: essid HousePublic b_num 167 mu_mac d8:9c:67:6c:1e:d5 macuser 0x4ae09ac
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  handle_sta_up_dn: mac d8:9c:67:6c:1e:d5 macuser 00x4ae09ac essid HousePublic user->essid HousePublic repready 0 repkey -1
    Apr 24 10:44:45 2024  authmgr[3736]: <522258> <5326> <DBUG> |authmgr|  "VDR - Add to history of user user d8:9c:67:6c:1e:d5 vlan 0 derivation_type Reset VLANs for Station up index 0.
    Apr 24 10:44:45 2024  authmgr[3736]: <522255> <5326> <DBUG> |authmgr|  "VDR - set vlan in user for d8:9c:67:6c:1e:d5 vlan 132 fwdmode 0 derivation_type Default VLAN.
    Apr 24 10:44:45 2024  authmgr[3736]: <522258> <5326> <DBUG> |authmgr|  "VDR - Add to history of user user d8:9c:67:6c:1e:d5 vlan 132 derivation_type Default VLAN index 1.
    Apr 24 10:44:45 2024  authmgr[3736]: <522255> <5326> <DBUG> |authmgr|  "VDR - set vlan in user for d8:9c:67:6c:1e:d5 vlan 132 fwdmode 0 derivation_type Current VLAN updated.
    Apr 24 10:44:45 2024  authmgr[3736]: <522258> <5326> <DBUG> |authmgr|  "VDR - Add to history of user user d8:9c:67:6c:1e:d5 vlan 132 derivation_type Current VLAN updated index 2.
    Apr 24 10:44:45 2024  authmgr[3736]: <522158> <5326> <DBUG> |authmgr|  Role Derivation for user N/A-d8:9c:67:6c:1e:d5- N/A Set AAA profile defaults.
    Apr 24 10:44:45 2024  authmgr[3736]: <522142> <5326> <DBUG> |authmgr|  Setting default role to authenticated for user d8:9c:67:6c:1e:d5".
    Apr 24 10:44:45 2024  authmgr[3736]: <522127> <5326> <DBUG> |authmgr|  {L2} Update role from logon to authenticated for IP=N/A, MAC=d8:9c:67:6c:1e:d5.
    Apr 24 10:44:45 2024  authmgr[3736]: <522049> <5326> <INFO> |authmgr|  MAC=d8:9c:67:6c:1e:d5,IP=N/A User role updated, existing Role=logon/none, new Role=authenticated/none, reason=Set AAA profile defaults
    Apr 24 10:44:45 2024  authmgr[3736]: <522341> <5326> <DBUG> |authmgr|  Client d8:9c:67:6c:1e:d5 idle timeout 300 profile global
    Apr 24 10:44:45 2024  authmgr[3736]: <522246> <5326> <DBUG> |authmgr|  Idle timeout should be driven by STM for MAC d8:9c:67:6c:1e:d5.
    Apr 24 10:44:45 2024  authmgr[3736]: <524141> <5326> <DBUG> |authmgr|  clr_pmkcache_ft():835: MAC:d8:9c:67:6c:1e:d5 BSS:68:28:cf:cc:96:80
    Apr 24 10:44:45 2024  stm[7292]:  <501100> <NOTI> |AP apLB2171@10.2.114.40 stm|  Assoc success @ 10:44:45.079287: d8:9c:67:6c:1e:d5: AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171
    Apr 24 10:44:45 2024  authmgr[3736]: <522254> <5326> <DBUG> |authmgr|  VDR - mac d8:9c:67:6c:1e:d5 rolename authenticated fwdmode 0 derivation_type Initial Role Contained vp not present.
    Apr 24 10:44:45 2024  authmgr[3736]: <522258> <5326> <DBUG> |authmgr|  "VDR - Add to history of user user d8:9c:67:6c:1e:d5 vlan 0 derivation_type Reset Role Based VLANs index 3.
    Apr 24 10:44:45 2024  authmgr[3736]: <522344> <5326> <DBUG> |authmgr|  handle_sta_up_dn (3942): rtts user=d8:9c:67:6c:1e:d5  enabled=0 initial tput=277333
    Apr 24 10:44:45 2024  authmgr[3736]: <524124> <5326> <DBUG> |authmgr|  auth_dot1x_supplicant_up(): MAC:d8:9c:67:6c:1e:d5, pmkid_present:False, pmkid:N/A
    Apr 24 10:44:45 2024  authmgr[3736]: <522255> <5326> <DBUG> |authmgr|  "VDR - set vlan in user for d8:9c:67:6c:1e:d5 vlan 132 fwdmode 0 derivation_type Current VLAN updated.
    Apr 24 10:44:45 2024  authmgr[3736]: <522258> <5326> <DBUG> |authmgr|  "VDR - Add to history of user user d8:9c:67:6c:1e:d5 vlan 132 derivation_type Current VLAN updated index 4.
    Apr 24 10:44:45 2024  authmgr[3736]: <522260> <5326> <DBUG> |authmgr|  "VDR - Cur VLAN updated d8:9c:67:6c:1e:d5 mob 0 inform 1 remote 0 wired 0 defvlan 132 exportedvlan 0 curvlan 132.
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  use mac d8:9c:67:6c:1e:d5 bssid 68:28:cf:cc:96:80 essid HousePublic msg mac d8:9c:67:6c:1e:d5 bssid 68:28:cf:cc:96:80 essid HousePublic
    Apr 24 10:44:45 2024  dot1x-proc:2[4399]: <522004> <4399> <DBUG> |dot1x-proc:2|  DO_HANDSHAKE: Dot1x user mac d8:9c:67:6c:1e:d5 bssid 68:28:cf:cc:96:80 essid HousePublic sta flags 0 fw_mode 0 apname apLB2171 group AG-LHOB-24OFF server_group  server  profile default-psk vlan 132 curacl_name authenticated ingress 66238 ft 0
    Apr 24 10:44:45 2024  dot1x-proc:2[4399]: <522004> <4399> <DBUG> |dot1x-proc:2|  handle_do_handshake for user d8:9c:67:6c:1e:d5
    Apr 24 10:44:45 2024  authmgr[3736]: <522308> <5326> <DBUG> |authmgr|  Device Type index derivation for d8:9c:67:6c:1e:d5 : dhcp (0,0,0) oui (0,0) ua (0,0,0) derived (0):
    Apr 24 10:44:45 2024  authmgr[3736]: <522050> <5326> <INFO> |authmgr|  MAC=d8:9c:67:6c:1e:d5,IP=N/A User data downloaded to datapath, new Role=authenticated/87, bw Contract=0/0, reason=layer 2 event driven download, Downloaded value for idle-timeout=10
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  auth_gsm_publish_channels: mac d8:9c:67:6c:1e:d5 publish_list 3 user VALID macuser VALID ipuser NULL 
    Apr 24 10:44:45 2024  authmgr[3736]: <522301> <5326> <DBUG> |authmgr|  Auth GSM : USER publish for uuid 204c030290a00000003149dd mac d8:9c:67:6c:1e:d5 name  role authenticated devtype  wired 0 authtype 0 subtype 0  encrypt-type 9 conn-port 8448 fwd-mode 0 roam 0 repkey -1
    Apr 24 10:44:45 2024  authmgr[3736]: <522287> <5326> <DBUG> |authmgr|  Auth GSM : MAC_USER publish for mac d8:9c:67:6c:1e:d5 bssid 68:28:cf:cc:96:80 vlan 132 type 1 data-ready 0 HA-IP n.a
    Apr 24 10:44:45 2024  authmgr[3736]: <522242> <5326> <DBUG> |authmgr|  MAC=d8:9c:67:6c:1e:d5 Station Created Update MMS: BSSID=68:28:cf:cc:96:80 ESSID=HousePublic VLAN=132 AP-name=apLB2171
    Apr 24 10:44:45 2024  dot1x-proc:2[4399]: <526162> <4399> <DBUG> |dot1x-proc:2|  wpa2_tx_eapolkey_mesg3:743 User-mac d8:9c:67:6c:1e:d5 bssid 68:28:cf:cc:96:80 RSNXE f4 01 20 PSK client,Opmode-Transition enabled
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <3736> <DBUG> |authmgr|  auth_handle_dot1x_key_handshake_data Updating PMK for client d8:9c:67:6c:1e:d5
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <3736> <DBUG> |authmgr|  Copying dot1x loginfo of size  88 with 4 entries to user d8:9c:67:6c:1e:d5
    Apr 24 10:44:45 2024  authmgr[3736]: <522004> <3736> <DBUG> |authmgr|  User published after receiving key data d8:9c:67:6c:1e:d5
    Apr 24 10:45:01 2024  stm[7292]:  <501102> <NOTI> |AP apLB2171@10.2.114.40 stm|  Disassoc from sta: d8:9c:67:6c:1e:d5: AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171 Reason STA has left and is disassociated
    Apr 24 10:45:01 2024  authmgr[3736]: <522296> <5326> <DBUG> |authmgr|  Auth GSM : USER_STA delete event for user d8:9c:67:6c:1e:d5 age 0 deauth_reason 8
    Apr 24 10:45:01 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  Delete STA: mac d8:9c:67:6c:1e:d5 Reason 8
    Apr 24 10:45:01 2024  authmgr[3736]: <522036> <5326> <INFO> |authmgr|  MAC=d8:9c:67:6c:1e:d5 Station DN: BSSID=68:28:cf:cc:96:80 ESSID=HousePublic VLAN=132 AP-name=apLB2171 reason=8 at 10:45:00.580576
    Apr 24 10:45:01 2024  authmgr[3736]: <522234> <5326> <DBUG> |authmgr|  Setting idle timer for user d8:9c:67:6c:1e:d5 to 300 seconds (idle timeout: 300 ageout: 0).
    Apr 24 10:45:01 2024  authmgr[3736]: <522152> <5326> <DBUG> |authmgr|  station free: bssid=68:28:cf:cc:96:80, mac=d8:9c:67:6c:1e:d5.
    Apr 24 10:45:01 2024  authmgr[3736]: <522244> <5326> <DBUG> |authmgr|  MAC=d8:9c:67:6c:1e:d5 Station Deleted Update MMS
    Apr 24 10:45:01 2024  stm[3758]: <501000> <3758> <DBUG> |stm|  Station d8:9c:67:6c:1e:d5: Clearing state
    Apr 24 10:45:01 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  d8:9c:67:6c:1e:d5: station datapath entry deleted
    Apr 24 10:45:01 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  mac_station_free: Sta->essid HousePublic mu_mac d8:9c:67:6c:1e:d5 macuser 0x0x4ae09ac
    Apr 24 10:45:01 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  ac_active_remove_mac_from_bucket: station d8:9c:67:6c:1e:d5 in essid HousePublic (mh_entry found True addr 0x4ae09ac) removed in bucket-map 167
    Apr 24 10:45:01 2024  authmgr[3736]: <522004> <5326> <DBUG> |authmgr|  auth_cluster_del_active_mac essid HousePublic b_num 167 mu_mac d8:9c:67:6c:1e:d5 mac_user 0x4ae09ac cluster_enabled=1
    Apr 24 10:45:01 2024  authmgr[3736]: <522290> <5326> <DBUG> |authmgr|  Auth GSM : MAC_USER delete for mac d8:9c:67:6c:1e:d5
    Apr 24 10:45:01 2024  authmgr[3736]: <522303> <5326> <DBUG> |authmgr|  Auth GSM : USER delete for mac d8:9c:67:6c:1e:d5 uuid 204c030290a00000003149dd 
    Apr 24 10:45:01 2024  stm[7292]:  <501000> <DBUG> |AP apLB2171@10.2.114.40 stm|  Station d8:9c:67:6c:1e:d5: Clearing state
    Apr 24 10:45:01 2024  stm[7292]:  <501093> <NOTI> |AP apLB2171@10.2.114.40 stm|  Auth success: d8:9c:67:6c:1e:d5: AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171
    Apr 24 10:45:01 2024  stm[7292]:  <501095> <NOTI> |AP apLB2171@10.2.114.40 stm|  Assoc request @ 10:45:01.496224: d8:9c:67:6c:1e:d5 (SN 0): AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171
    Apr 24 10:45:01 2024  stm[3758]: <501100> <3758> <NOTI> |stm|  Assoc success @ 10:45:01.509965: d8:9c:67:6c:1e:d5: AP 10.2.114.40-68:28:cf:cc:96:80-apLB2171




  • 3.  RE: Random clients not getting DHCP address

    Posted 29 days ago




  • 4.  RE: Random clients not getting DHCP address

    EMPLOYEE
    Posted 29 days ago

    Have you opened a case with TAC?

    Are the APs connecting to a cluster?  How many nodes?  How long have the nodes been online?



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 5.  RE: Random clients not getting DHCP address

    Posted 28 days ago

    Hi Carson,

    Everything is working and we have hundreds of APs and thousands of clients.

    The issue is that we are slowly migrating wireless from another vendor to Aruba. 

    Majority of devices work after the migration, but a handful of devices just wont get DHCP with Aruba.

    If I move the device to the old wireless network, those same devices work just fine.

    I will open a TAC case and get them involved.

    Thanks!




  • 6.  RE: Random clients not getting DHCP address

    Posted 21 days ago

    We figured it out.

    For some reason some devices need 'Random Mac addressing' feature enabled. 

    Not sure why this is the case but as soon as we enable it, clients are able to obtain IP address.




  • 7.  RE: Random clients not getting DHCP address

    EMPLOYEE
    Posted 21 days ago

    That shouldn't be a requirement, but if randomized MAC addressing has caused your situation to start working then that sounds more like something on the DHCP server side.  Definitely something to bring up in the TAC case.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 8.  RE: Random clients not getting DHCP address

    Posted 21 days ago
    Hi,

    Is it possible the other wifi is containing your valid client from connecting to another ssid






  • 9.  RE: Random clients not getting DHCP address

    Posted 20 days ago

    If you want to start using MPSK at some point in future, you're going to want to turn random mac off for clients that do that.



    ------------------------------
    Nathan
    ------------------------------



  • 10.  RE: Random clients not getting DHCP address

    Posted 17 days ago

    Alex, what devices did you have to do that on?  We are getting the exact same thing on our 6300M and 6200 switches at one of our schools.  We run almost entirely Apple equipment which in this case are Ipads, tv's and a few Macbooks.




  • 11.  RE: Random clients not getting DHCP address

    Posted 17 days ago

    Hey Matt,

    We see the issue on different devices.  There's workarounds for Mobile devices and Windows clients, but our main problem now are Macbooks. If I take any of the problematic device to another floor with the old wireless they work just fine.  Once I bring them back to where the new Aruba wireless has been migrated they don't work. Opened a case with TAC now and trying to capture E2E traffic to where bootp is failing.  




  • 12.  RE: Random clients not getting DHCP address

    Posted 13 days ago

    A missing client VLAN in the switch trunk port on one of the controllers in the cluster was the Root Cause.

    If clients connect to the controllers with correct vlans, they work.

    If clients connect to the controller with the missing vlan, DHCP fails.

    It looks like once the client mac is added to the user table, it is permanently mapped to a host controller.

    But because we can randomize the mac-address for Windows and mobile devices, we can get it to work.

    As for Macbooks, once it fails we could not get it to work and no workaround.

    Does anyone know where I can find documentation on Controller clustering or AP/Client Tunnels if there is any?

    Thanks,




  • 13.  RE: Random clients not getting DHCP address

    EMPLOYEE
    Posted 13 days ago

    User guide or AOS 8 Fundamentals Guide

    Any specific question?

    show lc-cluster group-membership

    Shows the current status of the cluster, whether operating as L2 or L3.  Clusters should ALWAYS be operating in L2 for normal operations.  If the cluster is operating in L3 mode, then the most likely culprit is a lack of visibility on one or more VLANs.  Always add VLANs at the switch side first, making sure to span the VLAN to all necessary ports/switches so that all cluster members have access.  Then add the VLAN to the cluster members, preferably at a group level so that all cluster members get the exact same configuration.

    show lc-cluster vlan-probe status

    When cluster VLAN probe is failing on a VLAN, the status can be checked to figure out which VLAN is failing.  This will only show one failing VLAN at a time so you could potentially have to check multiple times if there are multiple VLANs with issues.  Best option is to check this at each cluster node.

    lc-cluster exclude-vlan 1

    At a bare minimum you probably need to exclude VLAN 1 from the VLAN probes.  All VLANs not used for client connectivity should be excluded from the probes.

    The bucketmap determines the mapping of client MAC address to UAC.  Technically the decision for that mapping is done well before the client is connected, and gets updated based on cluster membership.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------