Notes: 1. SFE accelerated NAT is in 33006+ builds but only in kernel 3.2 and newer 2. 'KRACK' vulnerability fixes were completed in r33678 for Broadcom, including k26 (33655) & k24 (33656); use 33772 or later.
3. Bridge modes on k4.4 devices may sometimes work in some configurations in certain builds but are not supported by the bcmdhd driver. Use client or repeater instead as WDS doesn't work with Broadcom ARM either (see Issues below).
4. PBR/UDP with SFE working again since r40513 (see 6729)
4. CAKE scheduler added since r40547 (see 5796)
Issues, observations, and/or workarounds reported: 1.Trendnet 81*DRU models are missing factory-to-flash 2.DNScrypt is mostly only using v2 protocols now, but requires Golang that DD can't use:6246 3.WDS does not work on Broadcom ARM devices (only MIPS<->MIPS) 4.K2.6 builds are broken since 38253(?) (GUI issues):6538 5.VAPs not working at boot; workaround startup command:
sleep 10;stopservice nas;stopservice wlconf;startservice wlconf;startservice nas
This appears fixed (only for unbridged VAPs?) with r40564:40566...
Important: if reporting any issues, provide applicable info (GUI syslog, `dmesg`, `cat /var/log/messages`, etc.)
Or put into SVN ticket. For firewall issues, also provide "iptables" info (`iptables -L`, `iptables -t nat -L`, & the /tmp/.ipt file).
Template to copy (after "Code:") for posting issues, be sure to include the mode in use (gateway, AP, CB, etc.):
WARNING:This thread is to report on flashing this experimental test build, providing important info for both developers and users. Always state your hardware model, version, mode (e.g. Repeater) and SPECIFIC build (e.g. 33555_NEWD-2_K3.x_mega-nv64k.bin). Please avoid discussions and create a new thread to discuss specific problems or questions, as this thread is for reporting, not support. Posts may be deleted or moved to keep this thread manageable and useful. If you don't understand the risks or what to flash and how, with a means of recovery if it bricks, do NOT flash this experimental test build.[
Last edited by kernel-panic69 on Sat Aug 31, 2019 19:52; edited 1 time in total
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r40863 std (08/31/19)
Kernel: Linux 4.4.190 #1108 SMP Sat Aug 31 05:13:36 +04 2019 armv7l
Previous: r40854
Mode/Status: Gateway / working
Reset: no
Issues/Errors: Working well so far. I still don't see a fix for fq_codel_fast in the change log so I'm not testing it this time.
Uptime: 2hrs 19min
Temperatures: CPU 69.1 °C / WL0 48.5 °C / WL1 54.2 °C
Router/Version: Tplink Archer C1900
File: archer-c1900-webflash.bin
Kernel: 4.4.190
Mode: Gateway / AP
Status: I decided to try setting up QoS and against my better judgement I decided to try fq_codel_fast even though I've seen some of the issues people have reported in the previous builds. As soon as I applied the settings it seems to have bricked my router. The web ui wasn't responding and I couldn't ping it either.
The scary part was my reset button didn't seem to work with resetting the nvram. I know some people reported in the previous builds the reset button wasn't working. I read how to reset on tplinks website and resetting nvram wasn't working with the physical button still. I decided to try holding the reset button as the device booted up and that seemed to work. I don't know if this was a DDWRT issue or a router issue because I've never used the physical reset button on my router.
After resetting to defaults and not using fq_codel_fast everything seems alright. I've been using multiple devices so far for the last few hours and everything seems fine.
flyzipper wrote:
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r40863 std (08/31/19)
Kernel: Linux 4.4.190 #1108 SMP Sat Aug 31 05:13:36 +04 2019 armv7l
Previous: r40854
Mode/Status: Gateway / working
Reset: no
Issues/Errors: Working well so far. I still don't see a fix for fq_codel_fast in the change log so I'm not testing it this time.
Uptime: 2hrs 19min
Temperatures: CPU 69.1 °C / WL0 48.5 °C / WL1 54.2 °C
... The scary part was my reset button didn't seem to work with resetting the nvram. I know some people reported in the previous builds the reset button wasn't working. I read how to reset on tplinks website and resetting nvram wasn't working with the physical button still. I decided to try holding the reset button as the device booted up and that seemed to work. I don't know if this was a DDWRT issue or a router issue because I've never used the physical reset button on my router...
... fq_codel_fast...
It bricked my Archer C1900 so I wouldn't try it.
Thanks.
Also, your experience with the reset button is much like what I described in the last build thread...
"... not sure if my R7000's reset button is flaky, but my device appears to require a power cycle before the reset button functions. Order of operations: enable fq_codel_fast > save > enable > *soft brick* > press reset button (doesn't work) > cycle power > still soft-bricked > reset button (works) > reconfigure from defaults > celebrate".
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r40863 std (08/31/19)
Kernel: Linux 4.4.190 #1108 SMP Sat Aug 31 05:13:36 +04 2019 armv7l
Previous: Kong 40270
Mode/Status: Gateway / working
Reset: Yes
Issues/Errors: Cake scheduler locked up the router and then reset button not working as described above. Power cycling the router gave a ~10 second window where I was able to log in and restore a 40863 backup I'd made previously. All good after that. Any longer than ~10 seconds and she locked up again.
Joined: 13 Aug 2013 Posts: 6866 Location: Romerike, Norway
Posted: Sun Sep 01, 2019 17:47 Post subject:
Router/Version: Asus RT-AC66U A1
Firmware: DD-WRT v3.0-r40863 giga (08/31/19)
Kernel: Linux 3.10.108-d8 #26412 Sat Aug 31 09:42:03 +04 2019 mips
Previous: 40784
Mode/Status: Gateway / working
Reset: No
Router/Version: Linksys E3200
File: dd-wrt.v24-40863_NEWD-2_K3.x_mega-e3200.bin
Kernel: 3.10.108
Mode: Gateway / AP
Status: This router doesn't get a ton of use. Maybe used a few hours per day by 1 to 2 people max. I reset the router because it was on a fairly old build before I updated it plus I have a really basic setup so setting everything back up doesn't take to long. So far everything seems fine. No complaints.
I think I know the answer to this already but is there any benefit to having SFE enabled on a router that can achieve the max speeds I pay for without it enabled? I'm guessing there is no point but would it cause any issues?
flyzipper wrote:
Cows wrote:
... The scary part was my reset button didn't seem to work with resetting the nvram. I know some people reported in the previous builds the reset button wasn't working. I read how to reset on tplinks website and resetting nvram wasn't working with the physical button still. I decided to try holding the reset button as the device booted up and that seemed to work. I don't know if this was a DDWRT issue or a router issue because I've never used the physical reset button on my router...
... fq_codel_fast...
It bricked my Archer C1900 so I wouldn't try it.
Thanks.
Also, your experience with the reset button is much like what I described in the last build thread...
"... not sure if my R7000's reset button is flaky, but my device appears to require a power cycle before the reset button functions. Order of operations: enable fq_codel_fast > save > enable > *soft brick* > press reset button (doesn't work) > cycle power > still soft-bricked > reset button (works) > reconfigure from defaults > celebrate".
I must have missed that post. I hadn't updated my router in a few weeks but I still follow the new build threads. I power cycled my router 2 times and held the reset button for 10-30 seconds after it was fully booted but nothing. So I turned off my router and held the reset button then turned the power back on and the reset finally worked. Thought I would post this in the chance anyone else was having the same issue.
which seems even worse after filtering packets smaller than 64 byte away.....
@kernel-panic69 I have just tried setting Group Key Renewal Interval to 0 but not help much, hangs still go on and usually happen after a while with huge amount of network loads. I've no ideas if the broadcom drivers are all alright now or still conflicts or deadlocks (from timers maybe?) inside.
For the situations in HK now, I'm too sad but I have to tell you that, I know here were a few innocent HK citizens had been KILLED by HK cops and DEAD just on the platform of Prince Edward MTR station here. That's why cops had to close the entire station and throw out all the press reporters before they indiscriminately beat random people inside the station. Now cops are crazy now, they beat even tourists, reports or any random citizens and random foreigners, by their hatred of millions of people and even the international society. Actually now things go more and more like what happened in Beijing 4th June 1989. Most of the arrested young protesters had been beaten until serious injury and nearly die inside the San Uk Ling Holding Center of cops, which confirmed by some medical staffs in North District hospital. Commies just wanna kill and enjoy watching people die.
BS: Is it possible/practical to include a line in the Notes for each new version to simply state the last "stable" build, in your opinion?
That is an impossible thing for anyone to state --- 'DD_WRT stable build'
Over the years I have found several that I believe are stable for certain routers but NO good for some others.
Like the r33772 many promote is dang good on the QCA EA8500 but is NOT work a damn on the E2500 nor is it good on the WRT54G units, IMO.
r33555 is way better on the last two mentioned.
Of course this all depends on what you are doing with the router.
e.g. clients on the E2500 r33772 guest br1 network cannot communicate amongst themselves so NO good for chromcast clients
same setup on the E2500 works great using r33555
This has always been and will continue to be ---> finds what works good for what you are using the router for
