Wireless Access

Don't know where else to post this.

We had two students bring in their MacBook Pros the other day.  Neither one getting to the WWW, or other internet applications that we tested.

ARUBA OS 6.1.3 Master and Local Controllers.  Enterprise DHCP/DNS etc.

Both running 7.2 - both connectiong to our WPA2 .1x network, would take approx 1 -2 minutes getting an ip address (both to the same vlan from a pool of /24 vlans).  "There are many other users (MAC and otherwise) using this vlan, successfully".

After getting a ip - they can ping the gateway, dns, etc.  But can not browse the net.

Reimaged both machines to 10.7.3 and all updates - same result.  We are at the end of things to try.  We have attempted all the solutions posted here and other places.

Any ideas from anyone?

I would open a support case with TAC.

---

@phil wrote:

Don't know where else to post this.

We had two students bring in their MacBook Pros the other day.  Neither one getting to the WWW, or other internet applications that we tested.

ARUBA OS 6.1.3 Master and Local Controllers.  Enterprise DHCP/DNS etc.

Both running 7.2 - both connectiong to our WPA2 .1x network, would take approx 1 -2 minutes getting an ip address (both to the same vlan from a pool of /24 vlans).  "There are many other users (MAC and otherwise) using this vlan, successfully".

After getting a ip - they can ping the gateway, dns, etc.  But can not browse the net.

Reimaged both machines to 10.7.3 and all updates - same result.  We are at the end of things to try.  We have attempted all the solutions posted here and other places.

Any ideas from anyone?

---

Have you done a user debug or "show auth-tracebuf" when the client is authenticating?

 

I have not. Do not where to start. I will get the machines back in and do what you indicate for troubleshooting. And open a support case. Thanks.

2 things to consider with the 10.7.2/3 that are not relevant to previous versions of Mac OSX

 

1 - Java is not enabled by default, you will need to do this in the Java Preferneces

2 - 10.7.2/3 has its own OCSP check turned on by default

 

Both those thing have caused problems here

I have a support case open.

These clients (I have one on my desk now) are getting associated.  After that it is 1 to 3 minutes before they get an ip from our dhcp server.  After getting an address, they can get to no where - no ping on or off the net they are on.

The  "show auth-tracebuf" shows a successful association.

rom the controller cli - I can ping this machine but the response is like 4 times slower than any other client ping on the same net or other net.

Need to do a packet capture, I guess.  Is that possible from the controller?

Yes it is. And that is exactly what you need to do, a packet capture.

 

TAC can help you set this up. Unfortunately I cannot find the specific instructions on how to do this.

Well, I spent a few hours with TAC troubleshooting this issue.  arp cache issue due to unix (MACs and the like) OS doing bootp, or some such nonsense :smileysurprised:

Here's the relevent KB article -

 

http://support.arubanetworks.com/Default.aspx?tabid=111&loc=https://kb.arubanetworks.com/cgi-bin/arubanetworks.cfg/php/enduser/std_adp.php?p_faqid=347&p_created=1233359162&p_sid=*ptRJWQk&p_accessibility=&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MjAzLDIwMyZwX3Byb2RzPSZwX2NhdHM9JnBfcHY9JnBfY3Y9JnBfc2VhcmNoX3R5cGU9YW5zd2Vycy5zZWFyY2hfbmwmcF9wYWdlPTEmcF9zZWFyY2hfdGV4dD1tYWMgZGhjcA!!&p_li=&p_topview=1

 

So did they above mentioned resolve the issue after you implemented the changes on your routers?

 

Curious to know we had similar issues but they were caused by ocsp certificate issues.

 

 

Seems to have. Cleared the arp cache, set arp timeout on router from 6 min. to 3 min.

Our MS dhcp server supports bootp in the advanced settings; made changes to all scopes for dhcp & bootp.

Thank you for updating us on the fix. :smileyhappy:

Another update; because this problem came back.:smileymad:

Seems our RAP config was set so the RAPs got an ip from a range in the same vlan (in a pool) as some of our wireless clients.  This led to duplicate IPs and the controller blocking the client mac as an arp spoof.  We removed that vlan from the pool for the client ssid(s) in question.