davidc502 wrote:

starcms wrote:

I haven't had a chance to try r5389 yet.  If reghack2 is only able to patch the world region on r5389, you should simply be able to change your router region to 00 (World) instead of US and get the same effect.

@david, have you modified mwlwifi (specifically mac80211.c) to keep amsdu disabled after the changes made in this commit?  https://github.com/kaloz/mwlwifi/commit … 3b24e78ba0

or is there a way for the user to now disable amsdu on their own after compilation because of that commit?

edit: Because I am currently running r5297 and amsdu is NOT disabled as it had been for months now in your builds.

The code has changed to a if else statement ... When you get a chance, take a look at line 733 and tell me what ye thinks??

This commit here. Look at the bottom of the page....  https://github.com/kaloz/mwlwifi/commit … 3b24e78ba0

EDIT ****   LOL  apparently you already have.

Is latency back up again with the new driver?

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

starcms wrote:

davidc502 wrote:

The code has changed to a if else statement ... When you get a chance, take a look at line 733 and tell me what ye thinks??

This commit here. Look at the bottom of the page....  https://github.com/kaloz/mwlwifi/commit … 3b24e78ba0

EDIT ****   LOL  apparently you already have.

Is latency back up again with the new driver?

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

davidc502 wrote:

starcms wrote:

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

By putting it in cron instead of in System-->Startup-->Local Startup (/etc/rc.local), will the 2 commands be initiated immediately upon boot instead of after all the init.d scripts?

I'll try it now and report back.

The reason I recommend disabling permanently in the driver is because there are absolutely zero side-effects from having it disabled, and it makes the router perform as it should in games (this only applies to the 1200/1900ac/acs models; the 3200acm handles AMSDU differently, isn't affected by these lines or edits, and works properly).

EDIT:

Entering:

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

in cron has no effect.  Amsdu stays enabled.  Just a guess but maybe the version of cron included doesn't support @reboot?

However, placing the two echo commands where I first mentioned works to execute them on boot.

Edit2: You can check the status with:

cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu

It'll say "tx amsdu: enable" if you haven't entered the echo commands or "tx amsdu: disable" if you have entered the echo commands.  But remember, amsdu has to be disabled BEFORE any of your STAs (devices) connect or those that connected before it was changed from enabled to disabled will still have it enabled.  Hence another reason I hope @david chooses to permanently disable it as it had been for the last 6+ months approx until this commit came out.  The commit is nice because it allows AMSDU to be able to be disabled after compilation, but it doesn't give a good way of disabling it -- more like a temporary disable.

Edit3: Just curious, @david, how did you get the diff command working in busybox?  Something simple we had overlooked a couple months ago when trying it or something more complicated?

starcms wrote:

davidc502 wrote:

The code has changed to a if else statement ... When you get a chance, take a look at line 733 and tell me what ye thinks??

This commit here. Look at the bottom of the page.... 

EDIT ****   LOL  apparently you already have.

Is latency back up again with the new driver?

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

adri wrote:

@starcms

With the latest build r5389 of @davidc502, reghack2 doesn't seem to work anymore.
It patches only the world domain in /lib/modules/4.9.58/cfg80211.ko, but no longer the US domain!
As a result, the bad DFS detection still says enabled.
I have a WRT1900ACS v1 and previously reghack2 was able to patch both domain regulations.
Have you seen similar behaviour or a workaround?

Adri.

I haven't had a chance to try r5389 yet.  If reghack2 is only able to patch the world region on r5389, you should simply be able to change your router region to 00 (World) instead of US and get the same effect.

I compiled netstat-nat and it works normally on the wrt1200ac. It would be realy kind if you could include it in your buildbot routine @davidc502 it is one of the most important tools like htop or iftop, dont really know why it is missing.

https://github.com/hnw/openwrt-packages-netstat-nat/

makedir wrote:

I compiled netstat-nat and it works normally on the wrt1200ac. It would be realy kind if you could include it in your buildbot routine @davidc502 it is one of the most important tools like htop or iftop, dont really know why it is missing.

https://github.com/hnw/openwrt-packages-netstat-nat/

This package source would need to be added to feeds prior to building. I am a bit concerned as to why this package has been around as long as it has, yet isn't a part of OpenWrt/LEDE... Meaning it isn't a part of either systems as you have to configure it separately to be included in the build.  To me, that's always a concerning red flag.

I'm familiar with netstat, but what does netstat-nat give you?  I'm assuming IPv4 nat related stats?

The only reason why it is not part of Lede/OpenWRT anymore is because the devs are morons and typical Linux geeks and sort everything out with "there is no maintainer for this package anymore" even if it still works fine.

hi
can you help in which version was "cmd 0x801d=MEMAddrAccess timed out" error fixed? i was running 4.9.20 from June with "bad" wifi driver but it was pretty stable, now i can't connect via wifi with build from 17nov (apparently, the previous one). I'd aso love to patch the system somehow directly, rather than going throught the lengthy upgrade procedure. Thanks!
UPDATE: copied 88W8964.bin and other changed files and got me /sys/kernel/debug/ieee80211/phy0/mwlwifi/info upgraded after reboot.. could be the fix (msg 368323)

New build is up r5389...  For ACM owners, the latest test wifi firmware has been included.

1. There was one wifi driver commit that was added.
2. mvebu: backport a kernel irq fix for setting IRQ affinity
3. There are other packages upgraded/changed... The list as usual is on the Github site.

davidc502 wrote:

New build is up r5389...  For ACM owners, the latest test wifi firmware has been included.

1. There was one wifi driver commit that was added.
2. mvebu: backport a kernel irq fix for setting IRQ affinity
3. There are other packages upgraded/changed... The list as usual is on the Github site.

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

mrm wrote:

davidc502 wrote:

New build is up r5389...  For ACM owners, the latest test wifi firmware has been included.

1. There was one wifi driver commit that was added.
2. mvebu: backport a kernel irq fix for setting IRQ affinity
3. There are other packages upgraded/changed... The list as usual is on the Github site.

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

Firmware Version    Lede Reboot SNAPSHOT r5113-2af10c30fe / LuCI Master (git-17.291.51172-a98548e)
Kernel Version    4.4.93
Local Time    Tue Nov 21 02:42:41 2017
Uptime    1d 15h 0m 46s

haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

AddRemover wrote:

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

Well I guess this answers my question. I have been running DD-WRT, currently r33772 on WRT3200, without issues of any kind. Was running DD-WRT because of issues when using LEDE. Was hoping to come back as I really prefer LEDE, but with wife's health issues and a teen girl in house I need a reliable Internet connection. Reboots and loosing wireless connections are not an option for me right now and for me DD-WRT does not suffer from these.

Hi, thanks for all work, kernel problem in Linksys WRT1900AC is fixed (Random Reset) ? or need use old kernel versions?

Firmware Version    Lede Reboot SNAPSHOT r5113-2af10c30fe / LuCI Master (git-17.291.51172-a98548e)
Kernel Version    4.4.93
Local Time    Tue Nov 21 02:42:41 2017
Uptime    1d 15h 0m 46s

starcms wrote:

adri wrote:

@starcms

With the latest build r5389 of @davidc502, reghack2 doesn't seem to work anymore.
It patches only the world domain in /lib/modules/4.9.58/cfg80211.ko, but no longer the US domain!
As a result, the bad DFS detection still says enabled.
I have a WRT1900ACS v1 and previously reghack2 was able to patch both domain regulations.
Have you seen similar behaviour or a workaround?

Adri.

I haven't had a chance to try r5389 yet.  If reghack2 is only able to patch the world region on r5389, you should simply be able to change your router region to 00 (World) instead of US and get the same effect.

@starcms,

It seems Lede has made some changes, causing the internal regdb in cfg80211.ko to be removed.
An external regdb in /lib/firmware/regulatory.db is always used now.
See the following commit https://git.lede-project.org/?p=source. … 7e52a527c0
It seems reghack2 is no working or easily adapted.

bill1228 wrote:

AddRemover wrote:

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

Well I guess this answers my question. I have been running DD-WRT, currently r33772 on WRT3200, without issues of any kind. Was running DD-WRT because of issues when using LEDE. Was hoping to come back as I really prefer LEDE, but with wife's health issues and a teen girl in house I need a reliable Internet connection. Reboots and loosing wireless connections are not an option for me right now and for me DD-WRT does not suffer from these.

There have been conflicting stories from folks using dd-wrt as to if this problem exists or not on those systems.

davidc502 wrote:

mrm wrote:

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

mrm wrote:

davidc502 wrote:

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

This recreated for me again.  It appears to have been aligned with my returning home with my phone (Moto/Android) at 17:58:03 timestamp in the logs:

Tue Nov 21 17:52:30 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:52:36 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2b:96
Tue Nov 21 17:52:38 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:57:33 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:57:39 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2b:96
Tue Nov 21 17:57:41 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:02 2017 kern.info kernel: [61505.750462] ieee80211 phy1: staid 3 deleted
Tue Nov 21 17:58:02 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 3)
Tue Nov 21 17:58:03 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:03 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 WPA: pairwise key handshake completed (RSN)
Tue Nov 21 17:58:03 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:03 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:05 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:05 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPREQUEST(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPACK(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4 Phone
Tue Nov 21 17:58:11 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: authenticated
Tue Nov 21 17:58:17 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK b4:52:7e:3a:a4:04
Tue Nov 21 18:01:36 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 18:01:36 2017 kern.info kernel: [61719.825738] ieee80211 phy1: staid 3 deleted
Tue Nov 21 18:01:36 2017 kern.info kernel: [61719.957752] ieee80211 phy0: staid 1 deleted
Tue Nov 21 18:01:36 2017 daemon.info hostapd: wlan0: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 1)
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.082449] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.088310] ieee80211 phy0: return code: 0x1111
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.092866] ieee80211 phy0: timeout: 0x1111
Tue Nov 21 18:01:45 2017 daemon.info hostapd: wlan0: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: deauthenticated due to local deauth request
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.110195] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.116080] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.120635] ieee80211 phy0: timeout: 0x001d

The last three lines repeat every 4-ish seconds, until...

Tue Nov 21 18:02:16 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 3)
Tue Nov 21 18:02:16 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: authenticated
Tue Nov 21 18:02:17 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 WPA: pairwise key handshake completed (RSN)
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPREQUEST(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPACK(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4 Phone
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.111803] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.117667] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.122224] ieee80211 phy0: timeout: 0x001d
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.125738] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.131604] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.136151] ieee80211 phy0: timeout: 0x001d

At the same time, the 3200ACM's CPU load gradually increased over 20 minutes until it plateaued at "1.87" average load.  Once there, it remained at that level.  The network connection was still usable by multiple devices (wired and wireless), but LuCI was noticeably slower.