Application Patrol Internal Error and WLAN Question
Options
Zyxel Employee
Hope someone can help ---
I've started to need to look at the log files of my USG60W, and are seeing the following message in the log file of my USG60W. After a reboot of the device, there could be up to 2 days without the error showing, though once it shows up, it just continues to periodically be recorded between 10 and 60 minutes until the next reboot.
Does anyone know the source of the error? Is this an error that causes other issues? What is needed to eliminate the error?
More troubling, I've noticed many of my devices need to be re-authorized due to a "STA Timeout", causing a lot of deauthorization and re-authorization of devices (with the 20 or so devices, there could be 150+ lines an hour in the log). The devices are the same day-in and day-out, so not sure why they're timing out. The DHCP Lease time is set to 7 days. Is there a switch setting in the USG to extend the STA Timeout or do I need to look at some setting within the devices? The devices seem to be Apple devices (sometimes timing out even when they're not being used, perhaps an app wakes up), though can also include a Zyxel WAP6804 set to extender mode. When that device goes through the STA Timeout cycle, the connection typically degrades not being able to re-register, then having too many attempts and being locked out, and within a few hours the device crashes requiring the device to be rebooted. The issue always starts with an STA Timeout being recorded on the USG60W. I've looked at the log of the extender and it's not useful information, seems to record every piece of system code being executed, and unable to filter or send the log.
Here's an example of a device appearing to time-out and require re-authorization in 3 hours, though I've seen the need to re-authorize sometimes as short as 5 minutes. When the WAP6804 starts it's re-authorization cycle, it can be as short as every minute or two:
For the past couple of weeks, I've had to reboot the network every 3-4 days, the WLAN seems to grind to a halt with issues. I'd be happy to send the entire log if helpful.
Device Specs:
USG60W
Firmware V4.60(AAKZ.1)
AP Firmware on device: V6.10 Patch 9
App Patrol Version: 3.2.4.239
Thanks in advance,
John
I've started to need to look at the log files of my USG60W, and are seeing the following message in the log file of my USG60W. After a reboot of the device, there could be up to 2 days without the error showing, though once it shows up, it just continues to periodically be recorded between 10 and 60 minutes until the next reboot.
16 | 2021-01-05 10:39:46 | warn | Application Patrol | App ID has been changed from 67157254 to 5889 | fe80::882:9012:fd71:c354 5353 | ff02::fb 5353 | Internal Error |
17 | 2021-01-05 10:39:07 | warn | Application Patrol | App ID has been changed from 5889 to 67157254 | fe80::882:9012:fd71:c354 5353 | ff02::fb 5353 | Internal Error |
More troubling, I've noticed many of my devices need to be re-authorized due to a "STA Timeout", causing a lot of deauthorization and re-authorization of devices (with the 20 or so devices, there could be 150+ lines an hour in the log). The devices are the same day-in and day-out, so not sure why they're timing out. The DHCP Lease time is set to 7 days. Is there a switch setting in the USG to extend the STA Timeout or do I need to look at some setting within the devices? The devices seem to be Apple devices (sometimes timing out even when they're not being used, perhaps an app wakes up), though can also include a Zyxel WAP6804 set to extender mode. When that device goes through the STA Timeout cycle, the connection typically degrades not being able to re-register, then having too many attempts and being locked out, and within a few hours the device crashes requiring the device to be rebooted. The issue always starts with an STA Timeout being recorded on the USG60W. I've looked at the log of the extender and it's not useful information, seems to record every piece of system code being executed, and unable to filter or send the log.
Here's an example of a device appearing to time-out and require re-authorization in 3 hours, though I've seen the need to re-authorize sometimes as short as 5 minutes. When the WAP6804 starts it's re-authorization cycle, it can be as short as every minute or two:
55 | 2021-01-05 10:11:57 | info | DHCP | DHCP server assigned 192.168.40.24 to iPad(5C:97:F3:BA:49:D9) | DHCP ACK | ||
56 | 2021-01-05 10:11:57 | info | DHCP | Requested 192.168.40.24 from iPad(5C:97:F3:BA:49:D9) | DHCP Request | ||
57 | 2021-01-05 10:11:56 | info | Wlan Station Info | STA Association. MAC:5C:97:F3:BA:49:D9, AP:Local-AP, SSID:Hopper-Condo-5 [count=2] | |||
58 | 2021-01-05 10:11:56 | notice | Wireless LAN | Station: 5c:97:f3:ba:49:d9 has authorized on Channel: 36, SSID: Hopper-Condo-5, 5GHz. Interface:wlan-2-1 | IEEE 802.11 | ||
59 | 2021-01-05 10:11:56 | notice | Wireless LAN | Station: 5c:97:f3:ba:49:d9 has associated on Channel: 36, SSID: Hopper-Condo-5, 5GHz. Interface:wlan-2-1 | IEEE 802.11 | ||
60 | 2021-01-05 10:11:53 | notice | Wireless LAN | Station: 5c:97:f3:ba:49:d9 has deauth by STA Timeout on Channel: 36, SSID: Hopper-Condo-5, 5GHz, Tx/Rx: 593914201/10739417 Bytes. reason 2, Interface:wlan-2-1 | IEEE 802.11 | ||
61 | 2021-01-05 10:11:53 | info | Wlan Station Info | STA Disassociation(2:PREV_AUTH_NOT_VALID) by STA Timeout. MAC:5C:97:F3:BA:49:D9, AP:Local-AP, interface:wlan-2-1, SSID:Hopper-Condo-5, Tx/Rx:605363003/11019467 Bytes, session time:3H:27M:58S | |||
For the past couple of weeks, I've had to reboot the network every 3-4 days, the WLAN seems to grind to a halt with issues. I'd be happy to send the entire log if helpful.
Device Specs:
USG60W
Firmware V4.60(AAKZ.1)
AP Firmware on device: V6.10 Patch 9
App Patrol Version: 3.2.4.239
Thanks in advance,
John
0
Comments
-
Hi @JJNAnswering the first question:You can ignore those application patrol message, this message means that the application patrol function is trying to identify and address the passing through traffic categories. When the category mismatched, it will show this kind of error and re-identify until correctly identified the traffic category.0
-
Hi Jeff,
Thanks for the message -- makes a lot of sense.
For those interested, I seem to better understand what was happening with the continual dropping of WIFI connections from STA Timeout. To make the users experience more seamless between 2.4 and 5GHz, I used the same SSID. What I believe happened is that several devices, especially Apple devices saw that as an opportunity to try to improve reception, and attempt to switch between the radios to determine which frequency was optimal, given that the SSID was the same. In doing so, the AP needed to disassociate the device, switch radios, re-associate, then the device or the AP Controller check the strength, determine the original radio was stronger, and take all the actions again. There were many, many STA timeouts being incurred as a result. What I did to solve this was first install an ethernet powerline adapter device and set the Zyxel WAP6804 as an AP vs. Extender. Then I separated the networks into two SSIDs, causing a bit more work on users to manually determine their best frequency, however it appears to reduce a significant and continual amount of radio switching from the Apple devices.
My only remaining issue is that the Zyxel WAP6804 continues to appear to have a few firmware related issues. These include:- The inability to set the time using an NTP server (the time is never set through the server). The time can be set manually, though if the device is cycled, the time needs to be manually re-set
- The amazing amount of log information from extremely detailed status of the devices operation with no way to sort, filter, etc. There are hundreds of lines of "user.debug kernel: [55390.410000] eth1_0 emac_lib_rxstatistics_counter: warn: system is overloaded : spend more ~10ms!" and "user.err syslog: rdmInit(): file /mnt/ccc/config.xml exists!!"
John
0 -
Hi @JJN
Thank you for your feedback.
Could you enter WAP6804 web GUI page and provide screenshot of the firmware version to us?
0 -
Hi @JJNReplied current symptoms you encounter.(1). The inability to set the time using an NTP server:We suggest that you can manually configure NTP server (e.q. time.google.com , time.apple.com)and wait within 1~2 mins it can sync with NTP server automatically.(2).Amazing amount of Kernel messages shown on log:You can ignore those messages, it won’t impact your service at all.0
-
Hi Jeff,
Sorry for the slow response to your message. Here's the screen shot of the firmware -- has a later firmware been released?
Thanks,
John
0
Categories
- All Categories
- 398 Beta Program
- 2.1K Nebula
- 117 Nebula Ideas
- 84 Nebula Status and Incidents
- 5.2K Security
- 99 USG FLEX H Series
- 248 Security Ideas
- 1.3K Switch
- 69 Switch Ideas
- 926 Wireless
- 35 Wireless Ideas
- 5.9K Consumer Product
- 213 Service & License
- 339 News and Release
- 72 Security Advisories
- 21 Education Center
- 5 [Campaign] Zyxel Network Detective
- 2.1K FAQ
- 1K Nebula FAQ
- 446 Security FAQ
- 238 Switch FAQ
- 215 Access Point FAQ
- 47 Consumer Product FAQ
- 142 Service & License FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 74 About Community
- 64 Security Highlight
