12-18-2019 12:33 AM
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
Solved! Go to Solution.
12-20-2019 03:46 PM
@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:
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:
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.
05-13-2020 06:51 PM
05-12-2020 09:34 PM
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
05-12-2020 12:34 PM
We have all kinds of Apple issues with our AP650’s.
05-01-2020 06:34 PM
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.
12-21-2019 12:39 AM
I downgraded all 3 WAP's to 8.4r11 and will test Monday.