Higher Education

On occasion I get a call from our helpdesk about a student laptop that will not connect our wireless. It will connect to the signal and I'll see it in the controller but it will not get an IP address. Currently I have a student with this very problem and he was kind enough to leave it at the helpdesk so we could troubleshoot it today. No matter what I do I cannot seem to get his laptop to get an address. And he tells me it works just fine everywhere else but here. (I hate it when they say that LOL)

 

Here is a look at its connection:

 

and

 

 

On the client side of things we have tried:

- disabling IPv6 (shouldn't matter but worth a shot)

- updating WLAN NIC drivers

- Deleting WLAN NIC out for device manager and reinstalling

- flushing cache

- ever popular disable/re-enable of WLAN NIC

- various CLI ipconfig /release & renew commands

- rebooting (of course)

 

On the controller side of things I have:

- checked the blacklists as this is blacklist type behavior, blacklist continually clear

- checked on signal strength to the client

- checked interference levels on the AP the client is trying to connect to

- Checked and double checked the DHCP server, always plenty of open leases for new clients

- issued a #clear IP DHCP binding on the controller in question just to make sure there were no DHCP lease issues

 

Not sure where to go from here gang, any ideas?

 

Can you please share the user-role ?

being that the user doesn't get an Ip, they never progress farther thant the initial pre-authentication role for the guest network:

 

Can you add the logon-control to the ACL list right at the top under that user-role

 

And also do the same to the guest-role

Here is the cp-initial list:

 

 

Then is the captive portal acl:

 

 

And then the guest vpn allowance ACL:

 

americanmcneil,

 

What is the ACL after the user authenticates?

 

 

The standard Guest roll on the controller, but the user doesn't make that far. I can still post if you like though

americanmcneil,

 

Please take a look at the troubleshooting cheatsheet here:  http://community.arubanetworks.com/aruba/attachments/aruba/84/106/1/Troubleshooting+Cheat+Sheet-.pdf to see how to turn on DHCP debugging...

 

 

 

OK, got that set. The student came by and got his laptop from the help desk. I am hoping he brings it back on Monday so I can continue to work on this. Any other suggestions for the meantime?

For any IP address acquisition issues, always issue the following on the controller:

 

configure terminal
logging level debugging network subcat dhcp
end

 Then, issue:

 

show log network 100 | include <clients_mac_address>

 This will tell you if the controller is getting the client's DHCPDISCOVER messages, as well as whether it is observing DHCPOFFERS from the server. Assessing the controller's observations of DHCP transactions will point you in the direction for troubleshooting. For instance:

• if DISCOVERs are seen but no OFFERs, go to the DHCP server to see if the DISCOVERs ever arrive
• If the DISCOVERs and OFFERs are seen on the controller, go to the client and do a packet capture to see if the OFFERs ever make it to the client.

Hope this helps a bit.

 

And don't forget to disable DHCP debugging when you're done:

configure terminal
no logging level debug network subcat dhcp
end

 

 

Awesome! The student dropped his laptop off again this morning so I am setting up debugging now from some stuff CJ sent, now I will be sure to try this too. Thanks for all of the support everyone!

ok so with the following on:

 

logging level debugging user-debug c0:18:85:7e:ec:69

then

show log user-debug all | include c0:18:85:7e:ec:69

 i get --->

 

Nov 10 13:55:51 :501109:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Auth request: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP auth_alg 0
Nov 10 13:55:51 :501093:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Auth success: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 13:55:51 :501095:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Assoc request @ 13:55:51.105243: c0:18:85:7e:ec:69 (SN 2): AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 13:55:51 :501100:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Assoc success @ 13:55:51.106686: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 13:55:51 :501100:  <NOTI> |stm|  Assoc success @ 13:55:51.162183: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 13:55:51 :500511:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, 0.0.0.0: Received association on ESSID: SurfCFCC Guest Mobility service ON, HA Discovery on Association ON, Fastroaming Disabled, AP: Name DT-A104-AP Group A Building BSSID d8:c7:c8:c6:31:71, phy g, VLAN 3808
Nov 10 13:55:51 :522295:  <DBUG> |authmgr|  Auth GSM : USER_STA event 0 for user c0:18:85:7e:ec:69
Nov 10 13:55:51 :522035:  <INFO> |authmgr|  MAC=c0:18:85:7e:ec:69 Station UP: BSSID=d8:c7:c8:c6:31:71 ESSID=SurfCFCC Guest VLAN=3808 AP-name=DT-A104-AP
Nov 10 13:55:51 :522077:  <DBUG> |authmgr|  MAC=c0:18:85:7e:ec:69 ingress 0x0x10050 (tunnel 80), u_encr 1, m_encr 1, slotport 0x0x2100 , type: local, FW mode: 0, AP IP: 0.0.0.0 mdie 0 ft_complete 0
Nov 10 13:55:51 :522264:  <DBUG> |authmgr|  "MAC:c0:18:85:7e:ec:69: Allocating UUID: 218.
Nov 10 13:55:51 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 0 derivation_type Reset VLANs for Station up index 0.
Nov 10 13:55:51 :522255:  <DBUG> |authmgr|  "VDR - set vlan in user for c0:18:85:7e:ec:69 vlan 3808 fwdmode 0 derivation_type Default VLAN.
Nov 10 13:55:51 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 3808 derivation_type Default VLAN index 1.
Nov 10 13:55:51 :522255:  <DBUG> |authmgr|  "VDR - set vlan in user for c0:18:85:7e:ec:69 vlan 3808 fwdmode 0 derivation_type Current VLAN updated.
Nov 10 13:55:51 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 3808 derivation_type Current VLAN updated index 2.
Nov 10 13:55:51 :522246:  <DBUG> |authmgr|  Idle timeout should be driven by STM for MAC c0:18:85:7e:ec:69.
Nov 10 13:55:51 :524141:  <DBUG> |authmgr|  clr_pmkcache_ft():988: MAC:c0:18:85:7e:ec:69 BSS:d8:c7:c8:c6:31:71
Nov 10 13:55:51 :522287:  <DBUG> |authmgr|  Auth GSM : MAC_USER publish for mac c0:18:85:7e:ec:69 bssid d8:c7:c8:c6:31:71 vlan 3808 type 1 data-ready 0
Nov 10 13:55:51 :524124:  <DBUG> |authmgr|  dot1x_supplicant_up(): MAC:c0:18:85:7e:ec:69, pmkid_present:False, pmkid:N/A
Nov 10 13:55:51 :522255:  <DBUG> |authmgr|  "VDR - set vlan in user for c0:18:85:7e:ec:69 vlan 3808 fwdmode 0 derivation_type Current VLAN updated.
Nov 10 13:55:51 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 3808 derivation_type Current VLAN updated index 3.
Nov 10 13:55:51 :522260:  <DBUG> |authmgr|  "VDR - Cur VLAN updated c0:18:85:7e:ec:69 mob 1 inform 1 remote 0 wired 0 defvlan 3808 exportedvlan 0 curvlan 3808.
Nov 10 13:55:51 :522232:  <DBUG> |authmgr|  Data ready: MAC=c0:18:85:7e:ec:69 def_vlan 3808 derive vlan: 0 auth_type 0 auth_subtype 0.
Nov 10 13:55:51 :500415:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, : Data ready message from auth default vlan 3808 assigned vlan 0, mobile assigned vlan 0, mobile home vlan 0
Nov 10 13:55:51 :500417:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, : Derived vlan 0 added to mobility data ready database
Nov 10 13:55:51 :522050:  <INFO> |authmgr|  MAC=c0:18:85:7e:ec:69,IP=N/A User data downloaded to datapath, new Role=SurfCFCC Guest-guest-logon/82, bw Contract=0/0, reason=layer 2 event driven download, idle-timeout=15300
Nov 10 13:55:51 :522242:  <DBUG> |authmgr|  MAC=c0:18:85:7e:ec:69 Station Created Update MMS: BSSID=d8:c7:c8:c6:31:71 ESSID=SurfCFCC Guest VLAN=3808 AP-name=DT-A104-AP
Nov 10 13:55:51 :522301:  <DBUG> |authmgr|  Auth GSM : USER publish for uuid 218 mac c0:18:85:7e:ec:69 name  role SurfCFCC Guest-guest-logon devtype  wired 0 authtype 0 subtype 0  encrypt-type 0 conn-port 8448 fwd-mode 0

 

with the following enabled:

logging level debugging network subcat dhcp

then

show log network 100 | include c0:18:85:7e:ec:69

i get nothing...

 

 

additional info:

 

(3200XM-Local-UnionStation) (config) #show ap association client-mac c0:18:85:7e:ec:69                                                                                                   
The phy column shows client's operational capabilities for current association

Flags: A: Active, B: Band Steerable, H: Hotspot(802.11u) client, K: 802.11K client, R: 802.11R client, W: WMM client, w: 802.11w client

PHY Details: HT   : High throughput;      20: 20MHz;  40: 40MHz
             VHT  : Very High throughput; 80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz
             <n>ss: <n> spatial streams

Association Table
-----------------
Name        bssid              mac                auth  assoc  aid  l-int  essid           vlan-id  tunnel-id  phy          assoc. time  num assoc  Flags  Band steer moves (T/S)
----        -----              ---                ----  -----  ---  -----  -----           -------  ---------  ---          -----------  ---------  -----  ----------------------
DT-A104-AP  d8:c7:c8:c6:31:71  c0:18:85:7e:ec:69  y     y      1    1      SurfCFCC Guest  3808     0x10050    g-HT-20-1ss  15m:35s      1          WAB    13/7

c0:18:85:7e:ec:69-d8:c7:c8:c6:31:71 Stats
------------------------------------------
Parameter                            Value
---------                            -----
Channel                              11
Channel Frame Retry Rate(%)          0
Channel Frame Low Speed Rate(%)      0
Channel Frame Non Unicast Rate(%)    0
Channel Frame Fragmentation Rate(%)  0
Channel Frame Error Rate(%)          8
Channel Bandwidth Rate(kbps)         93
Channel Noise                        93
Client Frame Retry Rate(%)           0
Client Frame Low Speed Rate(%)       0
Client Frame Non Unicast Rate(%)     0
Client Frame Fragmentation Rate(%)   0
Client Frame Receive Error Rate(%)   0
Client Bandwidth Rate(kbps)          0
Client Tx Packets                    30175
Client Rx Packets                    70
Client Tx Bytes                      605367
Client Rx Bytes                      10231
Client SNR                           24
A2c_SM SeqNum, Old SeqNums           21866 0

 

What output do you get with:

 

show datapath user table | include C0:18:85:7E:EC:69

 In a normal post-DHCP state, there will be an L2 entry (where the client shows IP = 0.0.0.0) created after the controller receives a frame from the client, and an L3 entry once the client sources an IP packet. Mid-dhcp, I would expect only the L2 entry. You not seeing DHCPDISCOVERs means that either something is wrong with logging (try removing the "| include mac_address" and looking at all network logs for dhcp traffic), OR the controller truly is getting no more frames from the station after it associates, which moves troubleshooting towards the client.

Well I am inclined to think that the controller is not getting the DHCP request at all. One of techs tried 5 times to get the updated driver for the wireless card installed on the laptop and it just will not install correctly. It keeps failing. This is a student machine so that is as far as we can go as far as working on it unfortunately.

 

also, show datapath user table | include c0:18:85:7e:ec:69 didn't show me anything either...

For giggle, here is one more run...

 

Nov 10 14:16:16 :500059:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69: Disassociation at 3888
Nov 10 14:16:16 :522296:  <DBUG> |authmgr|  Auth GSM : USER_STA delete event for user c0:18:85:7e:ec:69 age 0 deauth_reason 8
Nov 10 14:16:16 :522036:  <INFO> |authmgr|  MAC=c0:18:85:7e:ec:69 Station DN: BSSID=d8:c7:c8:c6:31:71 ESSID=SurfCFCC Guest VLAN=3808 AP-name=DT-A104-AP
Nov 10 14:16:16 :522234:  <DBUG> |authmgr|  Setting idle timer for user c0:18:85:7e:ec:69 to 15300 seconds (idle timeout: 15300 ageout: 0).
Nov 10 14:16:16 :522244:  <DBUG> |authmgr|  MAC=c0:18:85:7e:ec:69 Station Deleted Update MMS
Nov 10 14:16:16 :522301:  <DBUG> |authmgr|  Auth GSM : USER publish for uuid 218 mac c0:18:85:7e:ec:69 name  role SurfCFCC Guest-guest-logon devtype  wired 0 authtype 0 subtype 0  encrypt-type 0 conn-port 8448 fwd-mode 0
Nov 10 14:16:16 :522231:  <DBUG> |authmgr|  MAC=c0:18:85:7e:ec:69 Send Station delete message to mobility.
Nov 10 14:16:16 :501102:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Disassoc from sta: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP Reason STA has left and is disassociated
Nov 10 14:16:16 :501000:  <DBUG> |AP DT-A104-AP@192.168.254.216 stm|  Station c0:18:85:7e:ec:69: Clearing state
Nov 10 14:16:16 :522290:  <DBUG> |authmgr|  Auth GSM : MAC_USER delete for mac c0:18:85:7e:ec:69
Nov 10 14:16:16 :522303:  <DBUG> |authmgr|  Auth GSM : USER delete for mac c0:18:85:7e:ec:69 uuid 218
Nov 10 14:16:16 :522265:  <DBUG> |authmgr|  "MAC:c0:18:85:7e:ec:69: Deallocating UUID: 218.
Nov 10 14:16:16 :527004:  <INFO> |mdns|  mdns_parse_auth_useridle_message 169 Auth User Idle Timeout: MAC:c0:18:85:7e:ec:69
Nov 10 14:16:16 :527000:  <DBUG> |mdns|  mdns_client_purge 935 Purge mdns client, mac=c0:18:85:7e:ec:69, del_client = 1
Nov 10 14:16:16 :500418:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, : Derived vlan 0 deleted from mobility data ready database
Nov 10 14:16:16 :500059:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69: Station delete from auth at 3829
Nov 10 14:16:16 :501000:  <DBUG> |stm|  Station c0:18:85:7e:ec:69: Clearing state
Nov 10 14:16:16 :501102:  <NOTI> |stm|  Disassoc from sta: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP Reason STA has left and is disassociated
Nov 10 14:16:16 :501037:  <NOTI> |stm|  Station c0:18:85:7e:ec:69: no association found trying to disassociate to BSSID d8:c7:c8:c6:31:71 on AP DT-A104-AP
Nov 10 14:16:19 :501109:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Auth request: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP auth_alg 0
Nov 10 14:16:19 :501093:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Auth success: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 14:16:19 :501095:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Assoc request @ 14:16:19.139711: c0:18:85:7e:ec:69 (SN 2): AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 14:16:19 :501100:  <NOTI> |AP DT-A104-AP@192.168.254.216 stm|  Assoc success @ 14:16:19.141143: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 14:16:19 :501100:  <NOTI> |stm|  Assoc success @ 14:16:19.149793: c0:18:85:7e:ec:69: AP 192.168.254.216-d8:c7:c8:c6:31:71-DT-A104-AP
Nov 10 14:16:19 :500511:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, 0.0.0.0: Received association on ESSID: SurfCFCC Guest Mobility service ON, HA Discovery on Association ON, Fastroaming Disabled, AP: Name DT-A104-AP Group A Building BSSID d8:c7:c8:c6:31:71, phy g, VLAN 3808
Nov 10 14:16:19 :522295:  <DBUG> |authmgr|  Auth GSM : USER_STA event 0 for user c0:18:85:7e:ec:69
Nov 10 14:16:19 :522035:  <INFO> |authmgr|  MAC=c0:18:85:7e:ec:69 Station UP: BSSID=d8:c7:c8:c6:31:71 ESSID=SurfCFCC Guest VLAN=3808 AP-name=DT-A104-AP
Nov 10 14:16:19 :522077:  <DBUG> |authmgr|  MAC=c0:18:85:7e:ec:69 ingress 0x0x10050 (tunnel 80), u_encr 1, m_encr 1, slotport 0x0x2100 , type: local, FW mode: 0, AP IP: 0.0.0.0 mdie 0 ft_complete 0
Nov 10 14:16:19 :522264:  <DBUG> |authmgr|  "MAC:c0:18:85:7e:ec:69: Allocating UUID: 1019.
Nov 10 14:16:19 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 0 derivation_type Reset VLANs for Station up index 0.
Nov 10 14:16:19 :522255:  <DBUG> |authmgr|  "VDR - set vlan in user for c0:18:85:7e:ec:69 vlan 3808 fwdmode 0 derivation_type Default VLAN.
Nov 10 14:16:19 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 3808 derivation_type Default VLAN index 1.
Nov 10 14:16:19 :522255:  <DBUG> |authmgr|  "VDR - set vlan in user for c0:18:85:7e:ec:69 vlan 3808 fwdmode 0 derivation_type Current VLAN updated.
Nov 10 14:16:19 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 3808 derivation_type Current VLAN updated index 2.
Nov 10 14:16:19 :522246:  <DBUG> |authmgr|  Idle timeout should be driven by STM for MAC c0:18:85:7e:ec:69.
Nov 10 14:16:19 :524141:  <DBUG> |authmgr|  clr_pmkcache_ft():988: MAC:c0:18:85:7e:ec:69 BSS:d8:c7:c8:c6:31:71
Nov 10 14:16:19 :522287:  <DBUG> |authmgr|  Auth GSM : MAC_USER publish for mac c0:18:85:7e:ec:69 bssid d8:c7:c8:c6:31:71 vlan 3808 type 1 data-ready 0
Nov 10 14:16:19 :524124:  <DBUG> |authmgr|  dot1x_supplicant_up(): MAC:c0:18:85:7e:ec:69, pmkid_present:False, pmkid:N/A
Nov 10 14:16:19 :522255:  <DBUG> |authmgr|  "VDR - set vlan in user for c0:18:85:7e:ec:69 vlan 3808 fwdmode 0 derivation_type Current VLAN updated.
Nov 10 14:16:19 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user c0:18:85:7e:ec:69 vlan 3808 derivation_type Current VLAN updated index 3.
Nov 10 14:16:19 :522260:  <DBUG> |authmgr|  "VDR - Cur VLAN updated c0:18:85:7e:ec:69 mob 1 inform 1 remote 0 wired 0 defvlan 3808 exportedvlan 0 curvlan 3808.
Nov 10 14:16:19 :522232:  <DBUG> |authmgr|  Data ready: MAC=c0:18:85:7e:ec:69 def_vlan 3808 derive vlan: 0 auth_type 0 auth_subtype 0.
Nov 10 14:16:19 :500415:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, : Data ready message from auth default vlan 3808 assigned vlan 0, mobile assigned vlan 0, mobile home vlan 0
Nov 10 14:16:19 :500417:  <DBUG> |mobileip|  Station c0:18:85:7e:ec:69, : Derived vlan 0 added to mobility data ready database
Nov 10 14:16:19 :522050:  <INFO> |authmgr|  MAC=c0:18:85:7e:ec:69,IP=N/A User data downloaded to datapath, new Role=SurfCFCC Guest-guest-logon/82, bw Contract=0/0, reason=layer 2 event driven download, idle-timeout=15300
Nov 10 14:16:19 :522242:  <DBUG> |authmgr|  MAC=c0:18:85:7e:ec:69 Station Created Update MMS: BSSID=d8:c7:c8:c6:31:71 ESSID=SurfCFCC Guest VLAN=3808 AP-name=DT-A104-AP
Nov 10 14:16:19 :522301:  <DBUG> |authmgr|  Auth GSM : USER publish for uuid 1019 mac c0:18:85:7e:ec:69 name  role SurfCFCC Guest-guest-logon devtype  wired 0 authtype 0 subtype 0  encrypt-type 0 conn-port 8448 fwd-mode 0

 

I am not seeing any DHCP traffic anywhere...

Does "show log network 50" show ANY dhcp for any device?

 

Hello all, I'm running into a similar problem with a student's laptop (decided to post here since I felt it fits with the topic but will create new thread if necessary). Student brought in their laptop 4 days ago complaining about not being able to connect to internet. At the time, the problem was solved by running: 

ipconfig /release
ipconfig /flushdns
ipconfig /renew

 The student came back to me today saying that the connection was working fine up until this morning. I've spent 3 hours troubleshooting with no success (so hopefully some help from here is possible).

 

Symptoms:

- Brand new HP laptop running Windows 8.1

- I disabled all anti-virus/firewall software

- Laptop is set as DHCP

- Laptop displays valid IP Address, Subnet Mask, and Default Gateway

- Laptop's ipconfig displays an IP address that is already assigned to another device in another building

- I have been unable to force an IP change on the laptop

- Laptop cannot access Captive Portal directly or by redirect

 

Can anyone shed some light on this? 

 

Thanks

CJ - yes that command works as per normal with other devices and also with out the pipe delimiters...

Okay.  Last thing to try is to do a decrypted packet capture to see if ANYTHING is being sent:

packet-capture reset-pcap datapath-pcap

packet-capture datapath wifi-client [mac address] decrypted

 Attempt to connect the device, then type:

 

show packet-capture datapath-pcap

 ...to see if you see anything from that client...

 

 

 

 

If the student drops his laptop off again today CJ, I'll be sure to give those a shot. Thanks again everybody for everything so far.

 

Symptoms:

- Brand new HP laptop running Windows 8.1

- I disabled all anti-virus/firewall software

- Laptop is set as DHCP

- Laptop displays valid IP Address, Subnet Mask, and Default Gateway

- Laptop's ipconfig displays an IP address that is already assigned to another device in another building

- I have been unable to force an IP change on the laptop

- Laptop cannot access Captive Portal directly or by redirect

 

Can anyone shed some light on this? 

 

Thanks

---

What is the output of "show aaa timers"?

What is the lease time of your DHCP pool?

Do you have "enforce dhcp" enabled on your AAA profile?

 

 

(aruba-master) >#show aaa timers
(aruba-master) >
(aruba-master) >

 This is what displays when I enter that command.

 

I apologize but I'll make a disclaimer now - I'm VERY new to working with ArubaOS and also somewhat familiar with the interface.

 

How/where do I determine the lease time?

 

And no, enforce DHCP is not enabled.

 

I apologize for the lack of knowledge, but this current issue is one that's plaguing campus and my colleagues are not so ambitious to get this solved.

ldjamision,

 

The questions were pointed at americanmcneill specifically based on his client having a duplicate ip address.

 

Either way, you need to enter "enable" mode to run those commands.  Are you having the same problem with clients not getting an ip address?  You might want to open your own thread so that we can troubleshoot your circumstances separately, because there are many reasons why it would happen...

 

Also, what dhcp server provides ip addresses to your clients?  If you don't know, please ask your colleagues, so that we can also find out what the lease time is.

Run Malwarebytes on it. Windows 8 is horrible for getting malware.

--

Jim LucasWireless and Field Services Coordinator

Network Operations
SUNY Plattsburgh
101 Broad Street
Kehoe 415
Plattsburgh, NY 12901
(518)564-5322

We will occasionally run in to this issue. Same things we've noticed as well. I haven't been able to determine what causes it, or how it happens, because it occurs on both Windows and OS X. Haven't seen issues with smartphones/tablets. Rebooting the client doesn't solve the issue.

What we've done to resolve these one-off issues is clear the user's session on our controller. The client is then able to get a DHCP address successfully. Wish I could figure this one out...

Mike

---

@burbackm wrote:
We will occasionally run in to this issue. Same things we've noticed as well. I haven't been able to determine what causes it, or how it happens, because it occurs on both Windows and OS X. Haven't seen issues with smartphones/tablets. Rebooting the client doesn't solve the issue.

What we've done to resolve these one-off issues is clear the user's session on our controller. The client is then able to get a DHCP address successfully. Wish I could figure this one out...

Mike

---

burbackm,

 

What is your DHCP lease for those clients?  A like Ryan said, aleading cause is not setting your lease long enough, if clearing the client's session fixes the problem..