Host command timeout

[yuhhaurlin]

Please use this one to check this issue.

[aaron1959]

The Device must be a specific device of course do you agree that there are dozens of devices that don't have this issue with going in and out of range. The Only devices I'm aware of that have this specific issue were using Qualcomm chip-sets, has this changed? @yuhhaurlin has now acknowledged that he understands what it takes to reproduce the failure reliably so now it's a matter of time on that end. The only thing that could now possibly stop them is if they don't have access to a device with a Qualcomm chipset or a WRT3200ACM.

[ratsputin]

@aaron1959 In my case, both devices in question are Qualcomm (iPhone 6 and iPhone 6 plus). But, as I pointed out, both devices have to leave and return to cause the crash. Just one or the other leaving for at least an hour and returning will no longer cause the crash.

Previously, when the iPhone 6 plus left for a few hours (3-4) and returned, the crash was inconsistent. That has no longer happened since the latest commit by @yuhhaurlin.

[aaron1959]

The Sony and Samsungs with the Qualcomm snapdragon chips still seem to be able to do it on their own with the latest commit by @yuhhaurlin

[aaron1959]

Anyway @yuhhaurlin specifically asked awhile back about the Samsung S7 so I'm assuming he now has one. If he can go in and out of range with it while keeping it out of range for over an hour and do that a couple of times then it means he's running firmware that will solve my issues. With a Samsung S7 this issue has had no change in behavior to this point.

[ratsputin]

As expected, when we returned, the router crashed. I can post the crash information, but I assume it's not going to provide any information that's not already been provided.

I believe I can definitively say that my router is stable if just one device leaves/returns, but if two (or more) devices leave and return for at least an hour, a crash is guaranteed.

[aaron1959]

They may all use a common qualcomm Modem chip.

[Chadster766]

@lucize I've tested your wireless settings over a few days with the latest mwlwifi commit on the McDebian beta with Samsungs Galaxys and iPhones going in and out of range without a single timeout recorded in the journalctl.

[gsustek]

@Chadster766 here you are:

https://pastebin.com/4hCuE0yJ

i would like to install you version of debian for wrt3200acm, could you please pinpoint me for your repo, and why you use debian in such hardware, it's a router, do you have some kind off webui similar to luci(and packets....where do you find packets for arm, is it hard to compile it)?

Regards, Goran

[Chadster766]

@gsustek:

https://github.com/Chadster766/McDebian https://github.com/Chadster766/McDebian/wiki https://github.com/Chadster766/McDebian/issues/43

[ratsputin]

So, here's an interesting piece of behavior. Unfortunately, two factors changed, so I'm not immediately able to nail down which change resulted in the difference.

Previously, leaving the house with an iPhone 6 and an iPhone 6 plus, then returning an hour, or so later would cause a crash. Yesterday, the iPhone 6 plus was replaced with an iPhone 8 plus. This morning, we left the house (iPhone 6 and iPhone 8 plus) along with two other devices (iPhone 7 and 7 plus) that had been registered on the network for several hours. Only the 6 and the 8+ returned four hours later and there was no crash.

I don't know if the lack of the crash is the result of four devices leaving and only two returning or if it's due to the 6 plus being replaced by an 8 plus. Hopefully, I'll have more information on this over the next week.

Regarding the comment by @aaron1959, these are all Qualcomm devices according to the interwebs.

[Chadster766]

I've had no crashes with my S6 Plus during testing.

[WildByDesign]

My current uptime is approx. "5d 20h 35m" and I am having great difficulty in reproducing the issue the past few days.

I decided to follow recent suggestions by leaving the house with two mobile devices (iPad and iPhone) for several hours and returning home with both devices at the same time. This used to trigger the issue quite consistently. However, I was unable to reproduce it today for some reason.

[aaron1959]

I've been running a new build of dd-wrt 33816 I'm assuming it has the latest changes that everyone else have made, maybe @BrainSlayer can help here. It's been up for a couple of days and I've been in and out of range many times, before now it would have started having issues.

I still get this error when I leave and come back into range

Nov 26 17:53:58 DD-WRT kern.err kernel: [70004.793561] ieee80211 phy0: create ba result error 1 This output may be unique to dd-wrt. Even though I see this error in the log it doesn't seem to effect the operation.

[adamcarter1]

Hi @BrainSlayer and @yuhhaurlin

I’m using dd-wrt r33772 I have the 2.4 ghz and the 5 ghz named seperately.

I am now beginning to understand what people are experiancing. I have quite a few devices, however most stay in range and rarely disconnect.

Xbox 1s on 5ghz Nintendo switch on 5ghz Vizio tv on 5 ghz Ipad pro 12” on 5ghz 2 ipad minis on 5 ghz Iphone 6s on 5 ghz Iphone 6 on 5 ghz Macbook air on 5 ghz Macbook pro on wired Synology nas on wired Ecobee 3 on 2.4 ghz

For the most part i would say the last few builds using the new driver have been stable... although i dont think i have as many devices as some of you all.

Black friday came and we added a: Firestick on 5 ghz, Anova sous vide on 2.4 ghz

This brings me to the point.

I am noticing while setting up the anova sous vide i had plugged it in near me to set it up... then unplugged it once set up and moved it to the kitchen. When i unplugged it the router gui stalled, and the internet went down. I can’t explain it, but it is very reproducible. Plugging it back in does not help.

Side note for @BrainSlayer . Someguy posted a patch to allow sfe on the 3200acm when policy based routing is enabled. As it stands it doesn’t work in it’s current state. Any chance you can incorporate this patch? Thanks in advance.

[yuhhaurlin]

Please help to test this commit https://github.com/kaloz/mwlwifi/commit/d5c5b05c538ad678929f1ed2891dde25a6fdd3eb, Thanks.

[thagabe]

@yuhhaurlin Could your help me understand what you are trying to do with the commit? Reading up on null packets they are used for devices that are in power saving mode and another use case that is not relevant here. Your commit tittle "Don't ack null or qos null data packet." is ambiguous as shouldn't the router ACKNOWLEDGE that the device is in power saving mode thus "buffer" incoming data until the device sends an "up and active" null package?

[thagabe]

I will admit, my shortcomings, maybe the second case is the reason the driver locks up.

Active/Passive Scanning: The other reason why a STA will inform an access point to buffer its frames by sending a power man bit of "1" is when it’s ready to roam. Suppose a client has hit its roaming threshold and is seeking out another access point to associate to. In order to seek out other access points in the area it has to go off channel. By doing so, the STA tells the AP, buffer the frames man, ill be back for them in a bit!

The client will send a NULL FRAME to the access point with the man bit of 1. The STA goes offline and floods channels 2,3,4,5,6,7,8,9,10,11 (depending on configuration of the client of course) with probe request looking for other APs.

Source

[yuhhaurlin]

The commit does not affect the handling of power save mode for client.

[yuhhaurlin]

The commit will make sure station aging due to inactivity of client will take effect (checking by hostapd).

[thagabe]

gotcha

[BrainSlayer]

new dd-wrt testimages available ftp://ftp.dd-wrt.com/others/test/linksys-wrt3200acm/

[aaron1959]

@BrainSlayer Testing now.

[ratsputin]

Wow! My new iPhone 8 actually caused the crash all by itself. I was having trouble getting it off the 2.4GHz band over to the 5GHz band. While messing with switching (repeatedly), it crashed the router. I'll load up the patched firmware here shortly.

[yuhhaurlin]

With the latest commit?

[ratsputin]

@yuhhaurlin No, the version that had been more stable previously. I simply found it interesting that the behavior varies significantly based on the model of the device, even though both the iPhone 6 and 8 are apparently based on the Qualcomm chipset.

I have, however, upgraded to the latest commit as of about four hours ago, so I'll provide updates as I get more experience with it. I'll also try experimenting with the two older iPhones as well (the 6 and 6 plus).

[05dyna]

@BrainSlayer FWIW I don't have the Samsung S7 issue but I wanted to try r33857. It rebooted on me twice even after a clean install and erasing the nvram. Not sure what produced the first crash & reboot other than normal use . I was running a LAN Speed test on the 5ghz band at the time of the second crash. My 5ghz wireless client is a HP laptop running Win10 with an embedded Intel Dual band Wireless AC 3165 network adapter (with current driver 10/02/2017) which was never an issue before. I also have a Raspberry Pi3 connected to the 2.4ghz band. I reverted back to r33772 and the wrt3200 appears stable again for my wireless clients

[adamcarter1]

@05dyna... seems to me a classic paula abdul scenario...

Two steps forward. One step back...

[aaron1959]

@05dyna I am testing for the specific issue and the build is still working fine for me I loaded it from the Linksys Ui Keeping nvram info info. Anyway this has nothing whatsoever to do with host command time out so I'm waiting.

[ghost]

Anyone got any ideas why phy0 says 5 & 2G is enabled, has been this way for a few commits now (running latest commit).

root@WRT3200ACM:~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

driver name: mwlwifi chip type: 88W8964 hw version: 7 driver version: 10.3.4.0-20170810 firmware version: 0x0903bee1 power table loaded from dts: no firmware region code: 0x0 mac address: 60:38:e0:b9:8d:d2 2g: enable 5g: enable antenna: 4 4 irq number: 46 ap macid support: 0000ffff sta macid support: 00010000 macid used: 00000001 radio: enable iobase0: e0c00000 iobase1: e0e80000 tx limit: 1024 rx limit: 16384

Wifi for phy0 is set to AP, AC Only, VHT80, CH. 100

[Chadster766]

The radios have both 2.4 and 5ghz enabled but the should be only enable for one or the other.

[Chadster766]

Its enabled in the DTS file and is easy to fix.

[aaron1959]

dd-wrt 33857 test build No issues so far. Well in keeping on the Host command timeout theme, I have gone out of and come back into range a lot of times and no issue so far, also in the log I no longer get this error when going out of and coming back into range. kern.err kernel: [70004.793561] ieee80211 phy0: create ba result error 1 I was told long ago that this error doesn't mean anything but now it's suddenly gone in this build.

P.S. the same Samsung Galaxy S7 that was killing it before.

I also try to put blinders on when doing this testing and try to stay narrowly focused on only host command timeout and ignore anything that doesn't interrupt that specific test.

I'm starting to think the issue was taking place when the device was coming back into range and it acquires a 2.4 Ghz link first then as the signal gets stronger it switches to the 5 Ghz. Before this wasn't happening very smoothly, sometimes trying to go direct to 5 Ghz without first connecting to the stronger 2.4 Ghz signal.

[yuhhaurlin]

You can ignore the message if BA stream is established.

[yuhhaurlin]

Yes. DTS controls band setting.

[yuhhaurlin]

The last commit won't affect stability of system.

[aaron1959]

@yuhhaurlin before when I got that message do we know that BA stream is established? so then we can ignore it?

[yuhhaurlin]

Cat debugfs file ampdu.

[BrainSlayer]

@05dyna can't say much without logs from your side

[ghost]

@BrainSlayer From 33772 to 33857, NAS/USB support isn't working properly and getting weird errors in log. On a fresh install if both phy0 and phy2 are enabled both don't work at all.

[05dyna]

@BrainSlayer Understood, I’m not involved with the Samsung debacle. I only mentioned adverse effect r33857 was having with “known good” hardware in the event r33857 was going to be a model for future dd-wrt builds.

I don’t want to hijack thread here and I realize you are addressing another issue. I thought it might be helpful info knowing r33857 was causing other problems. Looking at the post directly above this post 33857 may have some other issue. I’ve already reverted back r33772 but if you want I could reinstall the test build and try to reproduce crash if you think it would be helpful. Let me know and I’ll PM you the log or post over on the dd-wrt forum wrt3200 thread, your call

[aaron1959]

@rs-se I found I had to reboot after I updated from 33772 to linksys to 33857 after this I rebooted once more and everything started working. In the past couple of builds I have had to toggle the 5 ghz off and on in the Ui to get the 5 Ghz working changing channels didn't help. Once up and running mine is doing fine testing multiple clients wired as well as 2.4 and 5 Ghz. Haven't tried usb or nas but the logs look normal so far.

[BrainSlayer]

@rs-se : no changes in that code and you have not give me detailed informations. weired errors is too unspecific

[BrainSlayer]

@05dyna: this testbuild is is for testing changes in mwlwifi since all current versions do crash the wifi driver at certain point with some devices. but for sure it only makes sense to test it, if you can report any details like crash logs

[lucize]

@yuhhaurlin a very interesting thing

Tue Nov 28 12:51:28 2017 daemon.info hostapd: wlan0: STA 40:40:a7:xx:xx:xx WPA: group key handshake failed (RSN) after 4 tries
Tue Nov 28 12:51:28 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 40:40:a7:xx:xx:xx
Tue Nov 28 12:51:28 2017 daemon.info hostapd: wlan0: STA a4:e4:b8:xx:xx:xx WPA: group key handshake failed (RSN) after 4 tries
Tue Nov 28 12:51:28 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED a4:e4:b8:xx:xx:xx
Tue Nov 28 12:51:30 2017 kern.info kernel: [86489.299022] ieee80211 phy0: staid 2 deleted
Tue Nov 28 12:51:30 2017 kern.info kernel: [86489.352005] ieee80211 phy0: staid 1 deleted
Tue Nov 28 12:51:33 2017 daemon.info hostapd: wlan0: STA 40:40:a7:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Tue Nov 28 12:51:33 2017 daemon.info hostapd: wlan0: STA a4:e4:b8:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request

so ~3 hours of away, the hostapd was cleared of stations, I expect not to crash after the stations are cleared, until now it didn't hapened

[gsustek]

yep it seems that you fix this issue,(in my case).. i wonder is this a bug, not be compliant on RFC (marvell or qualcomm), or a dirty hack? :-) i'm not complaining, just asking:-)

[BrainSlayer]

@05dyna i fixed the nas page issue. it was unrelated to this test here

[aaron1959]

dd-wrt 33857 is still fine with stations leaving and coming back as stated above by @lucize the behavior is different. I am still testing but I think it's encouraging so far.

[05dyna]

@BrainSlayer - r33857 was up six hours and crashed. I was getting very good speed test results however this time the crash did not occur while doing the Lan speed test like it did for me yesterday. I noticed the uptime restarted on the status page just after the 6 hour mark. here's a partial log.

Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.677615] Unable to handle kernel paging request at virtual address 00060030  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.684877] pgd = c0004000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.687593] [00060030] *pgd=00000000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.691200] Internal error: Oops: 17 [#1] SMP ARM  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.695921] Modules linked in: nf_nat_pptp nf_conntrack_pptp nf_nat_proto_gre nf_conntrack_proto_gre btmrvl_sdio btmrvl bluetooth mwifiex_sdio mvsdio sdhci_pxav3 sdhci_pltfm sdhci mmc_block mmc_core mwifiex mwlwifi mac80211 c  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.725866] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.65 #78  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.731898] Hardware name: Marvell Armada 380/385 (Device Tree)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.737841] task: df42a5c0 task.stack: df458000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.742393] PC is at br_netif_receive_skb+0x14/0x40  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.747291] LR is at br_pass_frame_up+0xac/0x13c  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.751927] pc : [<c05106f0>]    lr : [<c05107c8>]    psr: 20000113  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.751927] sp : df459d48  ip : d5ac2000  fp : dd0da000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.763454] r10: 0000008a  r9 : dd0da08a  r8 : d5ac24c0  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.768700] r7 : 00000000  r6 : 4a56e103  r5 : d5ad2000  r4 : dc297000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.775255] r3 : 00060000  r2 : dc297000  r1 : 00000000  r0 : 00060000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.781810] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.788975] Control: 10c5387d  Table: 1e62404a  DAC: 00000051  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.794745] Process swapper/1 (pid: 0, stack limit = 0xdf458210)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.800776] Stack: (0xdf459d48 to 0xdf45a000)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.805151] 9d40:                   dc297000 c05107c8 00000001 df459e0c dc297000 df459da0  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.813365] 9d60: dd0da076 00000000 00000000 d5ad24c0 b6e03860 bf07db5c dc297000 de5d9200  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.821579] 9d80: df459e3c dc297000 de5d9200 00000000 00000000 c0510d8c 00000000 00000400  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.829792] 9da0: df459da0 df459da0 00000000 00000001 00000000 dc297000 de0e0bc0 dc297000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.838006] 9dc0: 00000000 df459e3c dd0da08a d5ad2000 de5d9200 d5ad2000 00000000 c05110d4  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.846219] 9de0: 9183041a 00000eed 00000000 00000000 df425580 de0e4464 00000000 00000000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.854432] 9e00: df459e3f c01cfd0c df459e3f dc297000 df459e3c 00000001 c0510da8 c090512c  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.862646] 9e20: c0905124 c04068b0 02080020 c0925640 de02d500 c03fb48c 00000000 dc297000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.870859] 9e40: de0e46e0 00000018 de0e46e0 dc297000 de02d500 de0e46e0 e0e80000 bf0cf25c  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.879073] 9e60: 00000002 00000000 c0904464 dfbe0830 00000001 00000000 dfbe0788 00000040  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.887286] 9e80: dfbe082c df459ec8 1f39c000 c0409ba4 dfbe0830 00000001 00000040 0020747a  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.895499] 9ea0: c0902d00 0000012c df459ec8 c0409308 dfbe0780 c0844780 c092b732 c0905124  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.903713] 9ec0: c06b5870 c06bbe04 df459ec8 df459ec8 df459ed0 df459ed0 c0902080 00000000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.911926] 9ee0: 00000003 c090208c 40000003 c0902080 ffffe000 00000100 c0902080 c01268f0  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.920140] 9f00: 00000000 00000001 df405000 c083f1f8 c092ea80 00000009 00207479 c0902d00  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.928353] 9f20: c06013cc 00200040 df5ac760 c0842084 00000000 00000000 00000001 df405000  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.936566] 9f40: df458000 00000001 c0843168 c0126d10 c0842084 c0160b30 c0904724 e080210c  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.944780] 9f60: df459f88 e0802100 e0803100 c0101480 c0108020 60000013 ffffffff df459fbc  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.952993] 9f80: 00000000 c010b7cc 00000001 00000000 00000000 c0114540 ffffe000 c0904424  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.961206] 9fa0: 00000002 c0904474 00000000 00000000 00000001 c0843168 60000013 df459fd8  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.969420] 9fc0: c010801c c0108020 60000013 ffffffff 00000051 00000000 ffffe000 c01595ec  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.977633] 9fe0: c0912d5c c0682bd8 1f44006a c092e2d8 00000000 001015e8 fffdffff dfbf7fff  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.985850] [<c05106f0>] (br_netif_receive_skb) from [<c05107c8>] (br_pass_frame_up+0xac/0x13c)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21569.994588] [<c05107c8>] (br_pass_frame_up) from [<c0510d8c>] (br_handle_frame_finish+0x4f4/0x510)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.003587] [<c0510d8c>] (br_handle_frame_finish) from [<c05110d4>] (br_handle_frame+0x32c/0x3e8)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.012501] [<c05110d4>] (br_handle_frame) from [<c04068b0>] (__netif_receive_skb_core+0x6f0/0xadc)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.021589] [<c04068b0>] (__netif_receive_skb_core) from [<c0409ba4>] (process_backlog+0x84/0x124)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.030588] [<c0409ba4>] (process_backlog) from [<c0409308>] (net_rx_action+0x130/0x2d8)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.038717] [<c0409308>] (net_rx_action) from [<c01268f0>] (__do_softirq+0xe0/0x234)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.046495] [<c01268f0>] (__do_softirq) from [<c0126d10>] (irq_exit+0xac/0xd8)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.053751] [<c0126d10>] (irq_exit) from [<c0160b30>] (__handle_domain_irq+0x94/0xa4)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.061617] [<c0160b30>] (__handle_domain_irq) from [<c0101480>] (gic_handle_irq+0x48/0x74)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.070007] [<c0101480>] (gic_handle_irq) from [<c010b7cc>] (__irq_svc+0x6c/0x90)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.077522] Exception stack(0xdf459f88 to 0xdf459fd0)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.082594] 9f80:                   00000001 00000000 00000000 c0114540 ffffe000 c0904424  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.090808] 9fa0: 00000002 c0904474 00000000 00000000 00000001 c0843168 60000013 df459fd8  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.099020] 9fc0: c010801c c0108020 60000013 ffffffff  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.104095] [<c010b7cc>] (__irq_svc) from [<c0108020>] (arch_cpu_idle+0x34/0x38)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.111526] [<c0108020>] (arch_cpu_idle) from [<c01595ec>] (cpu_startup_entry+0x114/0x1d0)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.119828] [<c01595ec>] (cpu_startup_entry) from [<001015e8>] (0x1015e8)  
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.126646] Code: e1a04002 e592304c e3d30001 0a000007 (e1d023b0)   
Nov 28 11:38:04Nov 28 11:38:04 196.52.2.119196.52.2.119 kernelkernel: [21570.132772] ---[ end trace aeb10290e2dc4bd3 ]---  
Nov 28 11:38:41Nov 28 11:38:41 xx:xx:xx:xxxx.xx.xx.xx loggerlogger: : cron : cron daemon successfully stopped  
Nov 28 11:38:42Nov 28 11:38:42 xx:xx:xx:xxxx.xx.xx.xx process_monitorprocess_monitor: Restarting cron (time sync change) 

[davidc502]

So far 18 hours of uptime.. I see stations leaving and re-authenticating normally with nothing unusual in the logs.. I see a couple of wireless issues in the build/support thread, but nothing related to this specific wifi issue.

Will continue to monitor.

[ratsputin]

30 hours of uptime for me with no issues.