The DMESG errors you are experiencing are very similar to mine - and for most the same. My theory so far is that it is kernel related. 4.9.265/264 crashes consistently on my router. I haven't thought of IOS-devices actually causing the crash, so I will at some time do one more attempt, shutting all those down, and see if newer versions stay stable then. Anyway - for me this does not happen on builds with kernel 4.9.261. You might want to try 46069. That is the last build with the 4.9.261 kernel, that is stable on my setup, regardless of wifi clients. Thought this might be helpful.
Confirmed, thank you! Here's exactly what I did:
1) Borrowed an Apple iPad Air 2 running iOS 14.4.2 and confirmed on r46329 the same issue of webif down within 5 minutes of Apple connection (same today as last night's logs with the different Apple iPhone X device).
3) Result: webif is still up on r46069 over 30 minutes after explicitly connecting an Apple device, which is much longer than the 5 minutes max on at least the last couple of builds! I'll update if anything goes south, but r46069 seems to avoid at least the webif down after Apple connect issue!
UPDATE: Everything's still good here 6.5 hours after downgrding our ACSv2 from r46329 to r46069 and connecting an Apple device, so I've since upgraded our ACSv1 from r44048 to r46069, which is handling a client mix including multiple Apple devices quite nicely. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Some days ago I rolled back to r44048 because each subsequent release has problem with wifi and some Apple devices (as you can read in many posts in this forum) for my WRT1900ACSv2.
But anyway I'd like to try new releases to find out if such bugs will be resolved, but upgragading to this new one from r44048 I get router reset to defaults, despite I opt for don't reset
As reconfiguring from scratch requires me hours, I think I will stalk every new build post to ask if Apple/wifi issues are still a matter
Yes, r44048 definitely can't use the same nvram variables or backup file because the radio designations (among others) were changed (e.g., from "ath" to "wlan") in an intervening build.
Fortunately, these have two flash partitions (although it's not really necesssary for this procedure, but does save the step of otherwise having to reflash r44048 every time)! Let's call the first flash area PRODUCTION (e.g., r44048) and the second flash area SANDBOX (e.g., r46316).
This procedure requires an nvram backup file of a reasonably recent build, but only for restoring to that very same build. What you have to do before flashing the latest beta release (e.g., 46329), is to:
first backup your r44048 nvram,
then erase nvram,
then switch to the SANDBOX partition (e.g., 46316),
then restore ITS corresponding same-build backup,
disconnect from Internet, etc.,
switch back to the PRODUCTION partition (not to run it just now but only to preserve r44048 so it doesn't have to be reflashed every time, since it always flashes over the partition that's NOT active),
and then flash r46329 or whatever into the SANDBOX partition WITHOUT RESET (ideally from telnet rather than webif, but webif does seem to work most of the time).
If the release still has Apple issues:
DO AN NVRAM BACKUP ANYWAY for the build since you might need it to perform the same procedure for the next release candidate,
optionally erase nvram,
then switch back to the PRODUCTION partition,
and finally restore a proper r44048 nvram backup file.
I've got a feeling I might get some pushback on the above, so let's just be clear that the only potentially kludgy part of this is switching back to the PRODUCTION (r44048) partition after restoring nvram while in the SANDBOX (e.g., r46316) partition. AFAIK, this step can only be avoided by treating the device as if it only had one partition and doing twice as much flashing, but I understand the concern. If anyone knows a way to do it from telnet without actually switching (that is, so r44048 never boots after restoring r46316's nvram backup), that'd be amazing!
EDIT: OH!!! I just read the Cliff Notes at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=311117 and found that it should be possible to flash the currently active partition from telnet after all, therefore avoiding the potentially kludgy part mentioned above:
Quote:
1. Use the ubootenv get boot_part command to learn the current Partition in use.
2. Use the ubootenv set boot_part (1 or 2 – the opposite number returned in Step 1) command.
3. DO NOT REBOOT
4. In DD-WRT GUI – Administration Tab – Firmware Upgrade Sub Tab: Upload the new ’dd-wrt webflash.bin’ file for your Router & Hardware Version. MAKE SURE THAT NO RESET IS SELECTED.
5. After Firmware Upgrade is finished the Router will automatically reboot.
(attributed to unknown author, so thank you!)
EDIT 2: That didn't quite solve it, but here's what did to avoid the kludge by using telnet/ssh (actually easier then webif, IMHO):
1) Assuming currently on r44048 in first linux partition, with r46316 in second linux2 partition, and want to test r46329 instead in that second linux2 partition:
Code:
cd /tmp
nvram backup nvram-backup-ACSv2-r44048.bin (and can copy it out using WinSCP, if needed)
ubootenv get boot_part
ubootenv set boot_part 2
nvram erase
nvram restore nvram-backup-ACSv2-r46316.bin (after copying it in with WinSCP, if needed)
Thank you very much, I will refer to this next time I try a new build!
You're quite welcome! But as a follow-up, Fonzi's suggestion to try r46069 is working great for us with Apple devices, and r46069 CAN be used without reset to/from the current r46329 release, at least for my configurations. After switching to r46069, I wouldn't expect any issue testing the next release without reset, but do save an nvram backup from r46069 first.
I'd tested r46069 when it first came out with good results, although without focusing on Apple issues. I've now had r46069 back up on both of our ACS routers since yesterday, successfully supporting a mix of Apple, PC and other devices with no issues whatsoever! I've specifically tested Apple iPhone X and Apple iPad Air 2, each with the latest iOS 14.4.2, without issue. Even an Apple iWatch is getting an IP without issue, presumably via Bluetooth through one of the other Apple devices since I don't think it has its own wifi. We don't currently have any Apple Mac laptop or desktop computers to test with, but perhaps someone else who does can chime in. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Wireless Mode AP Wifi 5GHZ AC/N mixed VHT80
Wifi 2.4GHZ - Auto Channel NG-Mixed Wide HT40
Security WPA2 Enterprise with DD WRT Radius / WPA2(AES) Personal
Error Descriptions:
Httpd crashes. Reboot of DDWRT Router helps for some time. If Router is up, and I disable WLAN on a Client, Client can’t reconnect anymore to WLAN. Message “Access denied”. Other Clients are still connected. Only when reboot the Router again, all Clients are connected again, till httpd crashes.
Error Descriptions:
Httpd crashes. Reboot of DDWRT Router helps for some time. If Router is up, and I disable WLAN on a Client, Client can’t reconnect anymore to WLAN. Message “Access denied”. Other Clients are still connected. Only when reboot the Router again, all Clients are connected again, till httpd crashes.
Hi, as stated in this thread you are not alone with this router having these kind of crashes. Try build 46069 with kernel 4.9.261, and report back if that solves the crashes for you as well.
@ChrisCa:
Any Apple devices in the Wifi of yours?
Can you add the output of /var/log/messages and dmesg to your post?
I can only stress: My 1900acs v2 does work without any issues right through several online meetings on several devices.
Wired and wireless no problem at all!
But no Apple devices here...
Thank you very much, I will refer to this next time I try a new build!
Except the instructions are wrong, so nvram erase && reboot before restore.
Sorry, I could have sworn I'd fixed that after you'd first mentioned it. I've just changed the instance of "nvram erase" immediately before the restore to "nvram erase && reboot". Thank you! _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Thx, yes, one mac book pro, rest windows and android devices.
Downgraded to 46069 3 hours ago, no issue till now. All devices are still connected, devices also reconnect when wlan is disabled / and enabled again, and Gui is still accessible.