Random Packet Loss

[Joe]

I migrated from TP-Link Omada and now appear to be experiencing random packet loss when connected wirelessly. To rule out an issue with my network, I connected a laptop via Ethernet for 24 hours and experienced no issues. Today, I disconnected the Ethernet cable and began using the laptop wirelessly, but I keep experiencing random packet loss. Currently, I only have one access point, and the laptop is roughly 25 feet from it. This issue is occurring with other wireless devices as well such as an Amazon Alexa in the same room. The switch port providing power and connectivity to the access point is fine and has the same configuration that supported the TP-Link access point. Looking through the Windows 10 command prompt, the laptop shows between 40% and 65% signal strength when connected to 5GHz and 88% when connected to 2.4GHz. It’s possible it’s flipping back and forth from 2.4GHz and 5GHz.

The logs that specify this device have been posted at the link below. They appear to be saying the device is switching from VLAN1 to VLAN10. VLAN1 isn’t in use and VLAN10 is the intended VLAN. VLAN10 is configured on the SSID, too. Any ideas?

AP6-PRO Log for HP Laptop Only: AP Logs - Pastebin.com
AP6-PRO Full Log Dump: Full AP Log Dump - Pastebin.com

Devices:
HP Laptop running Windows 10
Cisco 3560-48FQM running latest stable IOS XE
AP6-PRO running version 2.0x

Interface Configurations:
Cisco 3650-48FQM
interface GigabitEthernet1/0/5
description Family Room AP
switchport trunk native vlan 666
switchport trunk allowed vlan 10,20,30,100
switchport mode trunk
switchport nonegotiate
speed 1000
duplex full
end

Interface Statistics:
GigabitEthernet1/0/5 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 7070.8bc4.6305 (bia 7070.8bc4.6305)
Description: Family Room AP
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is on, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:07:30, output 00:00:05, output hang never
Last clearing of “show interface” counters 3d18h
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 438000 bits/sec, 100 packets/sec
5 minute output rate 1530000 bits/sec, 168 packets/sec
37898380 packets input, 27802223428 bytes, 0 no buffer
Received 937338 broadcasts (643105 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 643111 multicast, 0 pause input
0 input packets with dribble condition detected
98844033 packets output, 121119007152 bytes, 0 underruns
Output 63035 broadcasts (0 multicasts)
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

Interface PoE Statistics:
3650-CORE#show power inline | i Gi1/0/5
Gi1/0/5 auto on 15.4 Ieee PD 4 30.0

[jeffk931]

It certainly looks like it’s flapping between 2ghz and 5ghz

Aug 22 19:31:05 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:31:06 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:33:00 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:34:03 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:03 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:40 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:41 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:39:25 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:31:05 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:31:06 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:33:00 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:34:03 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:03 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:40 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:41 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:39:25 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:31:05 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:31:06 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:33:00 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:34:03 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:03 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:40 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:36:41 OpenWrt daemon.warn hostapd: b6:e6:2c:eb:0e:2e: L2UF RXed from 2tz5QDlK__/b2:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58
Aug 22 19:39:25 OpenWrt daemon.warn hostapd: b2:e6:2c:eb:0e:2e: L2UF RXed from 5tz5QDlK__/b6:e6:2c:eb:0e:2e: Dropping 60:45:2e:6c:93:a5 sjsz 58

1. Is there only one Alta AP broadcasting the SSID? Any other access points broadcasting the same SSID?
2. Do you have fast roaming enabled on the SSID?

[Joe]

Good morning. Yes, there is only one access point broadcasting the SSID. This weekend, I intended to add a second AP6-PRO, but I may hold off considering this problem and the others I posted about this morning. Yes, fast roaming is enabled on this SSID in preparation for adding the second access point this weekend. WPA3 was also enabled, but I just disabled it to test.

[jeffk931]

Yeah - I would try disabling fast roaming, WPA3, and also set the SSID to either 2.4 or 5ghz only, not both. See if that helps, then start narrowing it down to a specific setting. Based on the logs I’d lean towards having both 2.4 and 5 enabled is the problem

[Joe]

If I cannot have both bands enabled on an SSID, there is no point in continuing on with the product.

[jeffk931]

It’s just a troubleshooting step. We need to see if the behavior changes if you force to a specific band. If it doesn’t, we change it back. If it does, then we troubleshoot why it’s flapping

[Joe]

I deleted my second post. Those issues were caused by spanning-tree being enabled on the Cisco switch inadvertently. All findings in the initial post were with spanning-tree disabled. Those issues still persist. I have disabled WPA3 on the Guest Wireless SSID, this is where the HP laptop is connected and lowered the 2GHz min. rate from 11000Kbps to 1000Kbps on the IoT SSID. The IoT SSID only has 2.4GHz enabled and configured.

[Joe]

I’m not sure if this counts, but earlier, after your request to split the bands, I modified the wireless NIC on the laptop to prefer 2.4GHz only. This worked, but I continued to experience random packet loss.

[jeffk931]

If you create a wireless SSID in the same VLAN as the mgmt IP of the AP so that your test PC gets an IP in the same subnet and ping the AP from your PC, do you still see the packet loss?

[Alta-Jeff]

Are you sure that your laptop has the latest WiFi drivers installed? Did you ever try a single band at a time, and what was the result of those tests?

[Joe]

I can look at the drivers, but it’s a corporate laptop, so if the drivers are outdated, I’ll be out of luck. I haven’t tried a single band yet, but I did remove 5GHz from my IoT SSID and lowered the 2.4GHz minimum rate from 11,000 Kbps to 1,000 Kbps after reading a few posts from other members with similar issues. After doing that, all of my IoT devices seem to be staying connected, and I was able to stream music uninterrupted for the remainder of the day on an Alexa in the same office as the laptop.

[Joe]

I will give this a try on Monday. The packet loss is noticed mostly when on Microsoft Teams meetings or when transferring files to a remote device. In my case, when uploading software updates to a few remote firewalls. When I’m connected with an Ethernet cable, there are no issues with Teams meeting or transfers.

[Jorge]

And … did you consider an interference on the WiFi? Did you run a scan to see which channel is the best to operate??

[Joe]

Yes, I ran a scan after installation and manually set the channels for both radios.

[Joe]

I think my problem is related to spanning-tree. With spanning-tree enabled I occasionally catch spanning-tree steps such as blocking and listening in the access point messages in /var/log which causes the access point to go offline. I enabled syslog so I can better catch what’s going on. Is anyone able to help pinpoint the issue with me? I have a lot of logs that may be able to help. On the Cisco switch I have rapid-pvst enabled and on the access points I have RSTP. Mesh is disabled on both access points, too.

[jeffk931]

I would turn on stp debugging on the Cisco side to see if you can gather any additional insight then work from there.

[Joe]

Will do! As for the HP laptop, the driver was outdated by more than a year. I just installed the latest driver from the Intel website, and I’ll monitor the performance throughout the day. Is it normal for the access points to momentarily go down when you make a simple change in the cloud controller such as assigning an image to a client?

[Joe]

When you disable STP in the cloud controller, does this not disable it on the access points? I ask, because I’m still seeing spanning-tree logs in /var/log when the access point goes offline.

[rutman286]

Addressing this specific question Joe, yes we have alerted the team of a few scenarios where change things in the cloud controller causes all clients to re-connect. I have found this to be most reproducible when manual power levels are set.

[Joe]

My power levels are set manually. Will this eventually be fixed?