Wireless Access

Hi all,

We are running AP135's on 7k controllers with a master. Recently we are having problems with disconnects occuring specifically on MacBooks. We now ran a Wireshark trace on the MacBook and we see that when the user complains about connectivity issues, the MacBook is ARPing the default gateway but is not getting a response. This one time this occured at 10:04 AM, in Airwave, when we check this session, we see Airwave registered this session till 10:18 AM, and also at 10:18 AM we see a "Load balancing" event, WITHOUT green confirmation.

Is this a known issue? Is there a relation between the unsuccesfull load balancing event?

Some more info:

MacBook Pro (Retina, 15 inch, medio 2014)

  Interfaces:

en0:

  Type kaart: AirPort Extreme  (0x14E4, 0x134)

  Firmwareversie: Broadcom BCM43xx 1.0 (7.21.95.175.1a6)

If the problem occurred BEFORE the load balancing event, no.

---

@cjoseph wrote:

If the problem occurred BEFORE the load balancing event, no.

---

But how correct are the timings in Airwave? I have noticed at previous troubleshooting that the end time of a session is often 15-20 minutes later then the actual disconnect/loss of connectivity. That's why I find it a bit strange.

---

@hill2button wrote:

---

@cjoseph wrote:

If the problem occurred BEFORE the load balancing event, no.

---

But how correct are the timings in Airwave? I have noticed at previous troubleshooting that the end time of a session is often 15-20 minutes later then the actual disconnect/loss of connectivity. That's why I find it a bit strange.

---

Type "show aaa timer" on the controller.  The default global user idle timeout is 300 seconds (5 minutes).  If this number was been changed to be longer, users would seem to have a longer session.  If the user closes their laptop, we keep them in the user table for 5 minutes by default, so that they can open their laptop and have to reauthenticate to the captive portal.  The side effect of making this longer, is that sessions would also seem to be longer in Airwave and on the controller.

 There is also a user idle timeout on the captive portal authentication profile, where if that was also edited, user sessions would seem longer for that captive portal.

Just a quick update...

I tried updated AOS and installing all the latest El Cap updates, but last night I lost access again from my MBP, about 2 minutes after opening the lid.  My iPhone still had access, so I jumped in to the controller and had a look at the session table entries for my laptop's IP.  Nothing there.

It still showed connected on OS X and on the controller.  Everything appeared fine, but the ARP entry for 10.1.1.1 (my gateway -- a Linux box, not the controller) was incomplete.  I tried pinging other hosts in the same subnet (which did still have ARP entries), but got zero replies from anyone.  Also tried pinging the MBP from the controller, and got 0 out of 5 replies back.

Out of curiosity, I fired up Wireshark and saw broadcasts from other hosts, so it seems like the wireless card is still hearing traffic, but it's like one of those creepy movies where you can hear everyone, but they can't hear you, and you're all like, uh oh, am I dead?

So much for the easy fix.  Guess it's time to turn on debugging and keep a second laptop nearby.  (SSH from an iPhone is not much fun.)

You might want to take a look at the Dashboard> Performance and take a look at the channel quality and utilization of those access points at that time.  If you have Airwave, you might want to take a look at the RF utilization, as well.

FWIW, I've been having a lot of trouble with my MBPr-13 and iPhone 6 recently.  With either device, I will be connected to WiFi with a good signal, but suddenly unable to ping anything on the network.  I can solve the problem immediately by disassociating and reassociating.

I have yet to find anything meaningful in the logs, traces, show commands, etc.  No ARM events or anything else I've been able to correlate.  My next step will be to check the dataplane sessions, but I haven't yet been within convenient reach of a wired computer to troubleshoot.  Most of the time I just grumble under my breath, reconnect, and go on about my business.

In my case, firmware is ArubaOS 6.4.2.9 with 2x AP105.  MBP is using the same Broadcom BCM43xx.

At work, I switched to using an Aerohive AP in my lab for comparison sake, and in the last couple months, I've had zero issues with the same MBP, same iPhone, and also my work iPhone 5S.  This leads me to believe the problem is either with the AP105 firmware, ArubaOS, or some interaction between them and the Apple drivers.  Troubleshooting is slow-going, as I focus on one change at a time, and only then when I'm feeling motivated enough to stop what I was doing to dig into it.

Probably not very helpful, but I did find it interesting that I'm having a similar problem, with the same chipset, and within one minor version of you.

See if any of both of your problems fall into the categories listed here:  http://community.arubanetworks.com/t5/Technology-Blog/Removing-the-Bottleneck-in-Wireless/ba-p/77978

Not to any degree within my control, given neighboring APs and such.  No RF-Protect license here, so that precludes spectral analysis.  But, I have performed a couple of site surveys and the spectrum is fairly clean for the number of SSIDs visible.  Obviously that will vary.

Another interesting data point -- I don't seem to have quite as much trouble with some other wireless devices -- e.g., other laptops, media devices, etc.  This could entirely be a Broadcom issue that some APs / firmware handle better than others.

All that said, that was a fantastic post.  Thanks for taking the time.

Please PM me your email address and I will send you a link so I can look over your logs.tar

That's a really kind offer, but I feel I should invest a little time trying to solve this more than casually before I offload the chore onto someone else.  :-)  Especially since I work for an organization that (among other things) supports Aruba wireless products.  In this case, I thought it was just something with my setup, and it hadn't offended me enough to warrant my full attention yet.  Seeing similar behavior elsewhere inspires a bit more curiosity.

I have other controllers and firmware at my disposal, so I'll try going down that path and see if there's any difference.  I also haven't turned on client debugging or (as I mentioned) looked at the dataplane status in-situ yet.

The hard part is waiting for it to decide to act up.  Although I haven't had to wait long recently, so if I don't get a chance soon after the next tweak, that's probably a good sign.

Thanks for helping!

@joseph: this part of your post: - Do not enable "Local Probe Request Threshold" with Clientmatch. - ClientMatch should fully replace the functionality of local probe request threshold in the SSID profile.  Enabling lprt unfortunately, will have access points ignoring clients that it should be servicing, unfortunately when ClientMatch is enabled.  Leave it at zero (the default).  

Is this still relevant and correct? Just to be sure, cause at this moment we do have both active simultaneously. However, this is on another SSID, not the SSID on which we have the issue.

---

@hill2button wrote:

Thanks for helping!

 

@Joseph: this part of your post: - Do not enable "Local Probe Request Threshold" with Clientmatch. - ClientMatch should fully replace the functionality of local probe request threshold in the SSID profile.  Enabling lprt unfortunately, will have access points ignoring clients that it should be servicing, unfortunately when ClientMatch is enabled.  Leave it at zero (the default).  

 

Is this still relevant and correct? Just to be sure, cause at this moment we do have both active simultaneously. However, this is on another SSID, not the SSID on which we have the issue.

---

Disabling lprt would be a troubleshooting step if you have problems on that SSID.  If it is a different SSID, you can leave it alone if you are not having problems.