Solved

Macbook Pro remains connected to AP230's but No Internet Access

  • 18 December 2019
  • 14 replies
  • 630 views
D

If the user disconnects from the wifi and reconnects then he will have internet access again but he has to do this a couple times an hour. It's an older macbook pro but it is utilizing 5G. Has anyone run across this before?

 

Here is are some sample logs with the error highlighted:

 

Log1

Middle Office 12/17/2019 15:58 D854A21D0194 Basic Tx probe resp (pwr 10dBm)

Front Office 12/17/2019 15:58 D854A21D8AE4 Detail Rx <specific> probe req (rssi -79dB)

Middle Office 12/17/2019 15:58 D854A21D01A4 Basic Sta(at if=wifi1.1) is de-authenticated because of STA roam away

Middle Office 12/17/2019 15:58 D854A21D01A4 Info Tx disassoc (reason 101 <n/a> pwr 11dBm)

Middle Office 12/17/2019 15:58 D854A21D01A4 Basic Sta(at if=wifi1.1) is de-authenticated because of notification of driver

Back Office 12/17/2019 15:58 D854A21D0324 Info Sending 1/4 msg of 4-Way Handshake (at if=wifi1.1)

Back Office 12/17/2019 15:58 D854A21D0324 Info Received 2/4 msg of 4-Way Handshake (at if=wifi1.1)

Back Office 12/17/2019 15:58 D854A21D0324 Info Received 4/4 msg of 4-Way Handshake (at if=wifi1.1)

Back Office 12/17/2019 15:58 D854A21D0324 Basic IP 172.17.33.44 assigned for station

Back Office 12/17/2019 15:58 D854A21D0324 Basic Tx auth <open> (frame 2 status 0 pwr 11dBm)

Back Office 12/17/2019 15:58 D854A21D0324 Basic Rx auth <open> (frame 1 rssi -65dB)

Back Office 12/17/2019 15:58 D854A21D0324 Basic Rx assoc req (rssi -65dB)

Back Office 12/17/2019 15:58 D854A21D0324 Info WPA-PSK auth is starting (at if=wifi1.1)

Back Office 12/17/2019 15:58 D854A21D0324 Basic Tx assoc resp <accept> (status 0 pwr 11dBm)

Back Office 12/17/2019 15:58 D854A21D0324 Info Sending 3/4 msg of 4-Way Handshake (at if=wifi1.1)

Back Office 12/17/2019 15:58 D854A21D0324 Info DHCP server sent out DHCP ACKNOWLEDGE message to station

Back Office 12/17/2019 15:58 D854A21D0324 Basic DHCP session completed for station

Back Office 12/17/2019 16:00 D854A21D0324 Info IPv6 address fe80::c17:5ea:2169:7d4 is snooped.

 

Log2:

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic Tx probe resp (pwr 11dBm)

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic Tx probe resp (pwr 11dBm)

Front Office 12/17/2019 15:57 D854A21D8AE4 Info Tx disassoc (reason 101 <n/a> pwr 11dBm)

Front Office 12/17/2019 15:57 D854A21D8AE4 Basic Sta(at if=wifi1.1) is de-authenticated because of STA roam away

Front Office 12/17/2019 15:57 D854A21D8AE4 Basic Sta(at if=wifi1.1) is de-authenticated because of STA roam away

Front Office 12/17/2019 15:57 D854A21D8AE4 Basic Sta(at if=wifi1.1) is de-authenticated because of notification of driver

Middle Office 12/17/2019 15:57 D854A21D01A4 Info DHCP server sent out DHCP ACKNOWLEDGE message to station

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic Rx assoc req (rssi -50dB)

Middle Office 12/17/2019 15:57 D854A21D01A4 Info Sending 3/4 msg of 4-Way Handshake (at if=wifi1.1)

Middle Office 12/17/2019 15:57 D854A21D01A4 Info station sent out DHCP REQUEST message

Middle Office 12/17/2019 15:57 D854A21D01A4 Info Sending 1/4 msg of 4-Way Handshake (at if=wifi1.1)

Middle Office 12/17/2019 15:57 D854A21D01A4 Info Received 2/4 msg of 4-Way Handshake (at if=wifi1.1)

Middle Office 12/17/2019 15:57 D854A21D01A4 Info PTK is set (at if=wifi1.1)

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic Rx auth <open> (frame 1 rssi -50dB)

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic Tx auth <open> (frame 2 status 0 pwr 11dBm)

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic Tx assoc resp <accept> (status 0 pwr 11dBm)

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic IP 172.17.33.44 assigned for station

Middle Office 12/17/2019 15:57 D854A21D01A4 Basic DHCP session completed for station

icon

Best answer by dgillespie 20 December 2019, 16:46

@Sam Pirok​ and @Lloyd Sommerer​  I have recently discovered that this issue is not only happening on the one Macbook Pro - there are some Dell laptops running Win10 that are having the same issue: they remain connected but have no internet access. This seems to be related to Roaming in two ways:

  1. when a client moves from one side of the office to another, it roams to a new AP but it takes 30 seconds to 1 minute for internet access to work again.
  2. when a client is situated in a middle proximity between two AP's, without moving it can roam between both AP's causing the internet to drop.

 

I did have another call with Aerohive and something that stuck out to the engineer was the results of the show log buff | incl watchdog command on one of the AP's. There were a lot of entries (about 20+) and it essentially means that packets are getting stuck in the AP. This is a good reason why a client would remain connected (with valid ip) but have no internet - so we have an idea of what is happening.

 

It led him to believe one of two things:

  1. the AP's don't like the latest HiveOS - 10.0r7a. For this he recommended I downgrade to 8.4.11 on the one AP which I haven't tried yet.
  2. there is an issue with the eth0 NIC on the AP. I don't believe this to be the issue because other AP's are showing more than normal (more than 2 or 3) entries as well with the show log buff | incl watchdog command.

 

I did disable Frame Burst on the radio profiles and this did not resolve the issue. I am going to be updating the drivers on the Win10 laptops and do more testing.

View original

14 replies

S
Userlevel 1

Those logs are indicated the device is roaming away from the AP. You might want to adjust the power on your APs a bit lower, so there is less overlap and clients will connect to an AP closer to them. That should reduce the unintentional roaming on your network. You can also disable lower data rates in your SSID optional settings to require a stronger connection between the device and the AP before the device can connect, which will also reduce the unintentional roaming.

D

Thanks @Sam Pirok​ for the response. In comparing radio profiles (AC) to what I had a few weeks ago (when we had major drops for a few hours) I found that the original was set to:

  • max transmit power = 20db
  • transmission power floor = 5db
  • transmission power max drop = 9db

 

And the new profile is set to

  • max transmit power = 10db
  • transmission power floor = 2db
  • transmission power max drop = 2db

 

So I have already lowered the power of the radio profiles by half. There were some other changes made as well and one stuck out:

  • Weak Signal Request Suppression which was disabled on the old profile and enabled on the new one with a threshold of 25db

 

The log entries I zeroed in on were:

  • Tx probe resp (pwr 11dBm)
  • Tx disassoc (reason 101 <n/a>   pwr 11dBm)

 

These events happen right before the Sta(at if=wifi1.1) is de-authenticated because of STA roam away event so if I am correlating correctly then what is happening is when the Macbook enters the potentialality of roaming to a new access point, it's SNR is lower than 25db so it doesn't pass this setting. What is odd is that it remains connected with a valid ip but no internet access. The user then disconnects and reconnects which works again for another 15 minutes.

 

I am going to be changing one setting at a time so I will update this post on what works. If you have any thoughts, please let me know.

L

I am having a similar problem with Mac Book Pros and our AP630/650s. I'm very interested in hearing what you find that helps.

D

@Sam Pirok​ and @Lloyd Sommerer​  I have recently discovered that this issue is not only happening on the one Macbook Pro - there are some Dell laptops running Win10 that are having the same issue: they remain connected but have no internet access. This seems to be related to Roaming in two ways:

  1. when a client moves from one side of the office to another, it roams to a new AP but it takes 30 seconds to 1 minute for internet access to work again.
  2. when a client is situated in a middle proximity between two AP's, without moving it can roam between both AP's causing the internet to drop.

 

I did have another call with Aerohive and something that stuck out to the engineer was the results of the show log buff | incl watchdog command on one of the AP's. There were a lot of entries (about 20+) and it essentially means that packets are getting stuck in the AP. This is a good reason why a client would remain connected (with valid ip) but have no internet - so we have an idea of what is happening.

 

It led him to believe one of two things:

  1. the AP's don't like the latest HiveOS - 10.0r7a. For this he recommended I downgrade to 8.4.11 on the one AP which I haven't tried yet.
  2. there is an issue with the eth0 NIC on the AP. I don't believe this to be the issue because other AP's are showing more than normal (more than 2 or 3) entries as well with the show log buff | incl watchdog command.

 

I did disable Frame Burst on the radio profiles and this did not resolve the issue. I am going to be updating the drivers on the Win10 laptops and do more testing.

J

Hi Derek

 

I would try 8.2r6 on one of your APs. We had similar issues here and going to that firmware seems to have fixed things for us.

 

D

I downgraded all 3 WAP's to 8.4r11 and will test Monday.

S

I am curious, did your downgrade to 8.4r11 resolve things?  We have the same issue on our AP230’s running 10.0r8 so I was just curious if it was resolved and came back or maybe our issue is not related to what you posted.

kevin.piazza
Userlevel 2

We have all kinds of Apple issues with our AP650’s.  @dgillespie any luck on the firmware downgrade?

Tomasz
Userlevel 6
Badge

Hi,

I had a similar behavior like this with one customer I met:

when a client is situated in a middle proximity between two AP's, without moving it can roam between both AP's causing the internet to drop.

Not sure if it was exactly the same issue as yours seem to be relevant for just few devices... they had very long beacon intervals (300 TUs, should be left default 100 in 99% of cases) and DTIM increased to 5. So the stations were allowed to sleep for about 300*5 = 1.5 second. Most likely because of that, every single minute a station standing in between two APs (-70 dBm RSS from each) was losing throughput down to 0 for 5-10 seconds and then finding the second AP. And after about a minute the same scenario and moving back to the first AP. Also site survey tool was showing BSSID graphs quite “chopped”. When we decreased beacon interval to 100 TU and DTIM to 2 it became normal.

 

Hope that helps,

Tomasz

D

@kevin.piazza@sglassman yes, the firmware downgrade fixed the issue for the Macbook but it still remained for a few windows clients.  I haven’t been able to test further since we are all working from home these days.

S
Userlevel 2

@kevin.piazza@sglassmanyes, the firmware downgrade fixed the issue for the Macbook but it still remained for a few windows clients.  I haven’t been able to test further since we are all working from home these days.

I know that windows 10 has an issue if its an Intel wifi card, and you have to go to intel and download the driver for it.  Once i did that it fixed most of my windows 10 issues.

 

I have firmware 10.0.5r5 and seem to have plenty of Macbook issues with wifi.   So thats interesting that you downgraded to 8.4r11 and it fixed your issue.  You are talking about the AP firmware right? for the AP650’s?  because that would be a major step back for us to do, if it were to fix all my macbook headaches!

kevin.piazza
Userlevel 2

Since upgrading to 10.0r9a and tweaking some radio config settings, our Apple devices have been performing much better. We’ve found potential issues or maybe even bugs within either the firmware or ExtremeCloudIQ that can severely change how our client devices perform.

With every ExtremeCloudIQ version update and AP650 firmware update, everything can change or break based on what Extreme updates. I’ve had basic setting changes break everything and clients couldn’t connect :tired_face::rage: . I know we noticed a big difference after we disabled “Enable short guard interval” and “Enable Aggregate MAC Protocol Data Units”. I would say that 10.0r8 was a frustrating firmware release and around that time there were plenty of bugs in the early stages of ExtremeCloudIQ.

Thankfully, things are getting better and having consistant firmware updates and IQ updates have made a big difference.

J

Hi Kevin

When you disabled “Enable short guard interval” and “Enable Aggregate MAC Protocol Data Units” you said you noticed a big difference. Was that for the good or the bad?

Thanks

S
Userlevel 2

Kevin, please let us know if the big difference was good or bad?

 

Because we are a school with a lot of Macbooks, your answer is important.  Thanks, J.

Reply