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 build 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. Since 39469, udhcpd was removed and replaced with the already present dnsmasq, and PIE qdisc was added for some builds.
5. Policy-Based Routing with SFE enabled was fixed in r39556: 5986 and 5900 6. k2.4 (broadcom/) builds were fixed in 39715 (broken in 39144 through 39654)
7.SFE update (k3.10+ for BCM) was in the 39927 build.
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 to be fixed for some routers (different kernels, modes, and radios) since build 39508.
Important: if any issues are found, please provide log info (GUI syslog, `dmesg`, `cat /var/log/messages`).
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.
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r40167 std (06/30/19)
Kernel: Linux 4.4.184 #347 SMP PREEMPT Sun Jun 30 09:29:35 CEST 2019 armv7l
Previous: r40134
Mode/Status: Gateway / working
Reset: no
Issues/Errors: Working so far.
Uptime: 21min
Temperatures: CPU 69.1 °C / WL0 48.5 °C / WL1 54.3 °C
Posted: Sun Jun 30, 2019 22:11 Post subject: Linksys EA6400
Router/Version: Linksys EA6400
File: DD-WRT v3.0-r40167 std (06/30/19)
Kernel: Linux 4.4.184 #347 SMP PREEMPT Sun Jun 30 09:29:35 CEST 2019 armv7l
Mode: Gateway/Router/Port Forwarding
Reset: No
Status: No issues so far.
Joined: 09 Nov 2014 Posts: 314 Location: Bakersfield, CA
Posted: Sun Jun 30, 2019 22:13 Post subject:
Router/Version: 2x Linksys E3000
Firmware: dd-wrt.v24-40167_NEWD-2_K3.x_mega-e3000.bin
Previous: dd-wrt.v24-40134_NEWD-2_K3.x_mega-e3000.bin
Kernel: Linux 3.10.108-d8 #25173 Sun Jun 30 15:54:36 CEST 2019 mips
Mode: Client Bridges
Status: So far so good, been running it since it's been uploaded to the ftp. :) _________________ Deployed Routers:
Netgear R7800 - 1x build 46979
- Gateway (USB /w Entware, CAKE QoS)
Netgear R7000 - 3x build 46979
Last edited by SinCalChewy on Mon Jul 01, 2019 9:49; edited 1 time in total
Router/Version: Linksys EA6300
File: DD-WRT v3.0-r40167 std (06/30/19)
Kernel:
Mode: Gateway/Router/Port Forwarding
Previous: Firmware: DD-WRT v3.0-r39927 std (06/03/19)
Reset: No
Status: this firmware Cann't boot correctly, I have try to flash via command mtd or upgrade.asp to flash firmware r40167 and r40134, both cann't boot correctly, but r40065 is work very well.
It's very strange
Router/Version: Cisco Linksys E4200 v1
File: dd-wrt.v24-40167_NEWD-2_K3.x_mega-e4200.bin
Firmware: DD-WRT v3.0-r40167 mega (06/30/19)
Kernel: UNK (see below)
Previous: DD-WRT v3.0-r40065 mega (06/20/19)
Reset: No
Mode: Gateway/AP
Uptime: 0
Status: Bricked; reverted back to DD-WRT v3.0-r40065 mega (06/20/19)
Issues/Errors:
See attached logs. I could've tried to flash from 35531 K3.x during recovery process, but I chose not to. Seems like there's some commits that need to be reverted. I guess I will find out if the GTK renewal interval bug is still present as I didn't change that. Yet.
Joined: 08 May 2018 Posts: 14222 Location: Texas, USA
Posted: Mon Jul 01, 2019 19:07 Post subject:
parco wrote:
@kernel-panic69
What is the Network paramenters "TX Queue Length" for actually? Does it improve anything if I modify "TX Queue Length" for eth and vlan?
I sent you a pm.
Back to topic, I am trying to think of what may have caused my brick other than a bad flash OR the threading changes to httpd OR something else. I have another test unit I can check with, it's already serial recovery ready.
EDIT: Looks like perhaps the problem was fixed and should be good in next build https://svn.dd-wrt.com/changeset/40182. However, the actual problem for N-devices with dual band is that the default vlan settings and some other things are incorrect and haven't been fixed in public betas, but I have no GLUE I guess if I were to reset to defaults or try flashing this build on the test bench unit and not touch the vlans page whatsoever, if might be fine
Joined: 18 Jul 2017 Posts: 45 Location: Wisconsin, USA
Posted: Tue Jul 02, 2019 15:48 Post subject: Bricked - Don't Flash to EA6500 V1
I've been sitting here quietly updating my firmware every release and for awhile things have been good but I thought I would chime in. This release (40167) and the one before (40134) both bricked my device. I was able to recover by using TFTP in both cases. I have also been rolling back to 40065 as it is stable
Router/Version: Linksys EA6500 v1
Firmware: Firmware: DD-WRT v3.0-r40167 giga (06/30/19)
Kernel: Unknown as it wont boot.
Previous: DD-WRT v3.0-r40065 giga (06/20/19)
Mode/Status: Gateway/AP
Setup: Using IPv6 via DNSMasq, DDNS, & Port Range Forward.
Reset: No
Issues/Errors: Device Bricked with both versions 40134 & 40167 _________________
Router/Version: Asus RT-AC1900P
File: asus_rt-ac1900p-firmware.trx
Kernel: Linux 4.4.184 #347 SMP PREEMPT Sun Jun 30 09:29:35 CEST 2019 armv7l
Mode: Gateway/AP
Reset: No
Uptime: ~20 hours
Status: OK
Router/Version: Asus RT-AC3100
File: 2019-06-30_asus_rt-ac3100-firmware.trx
Kernel: Linux 4.4.181-rc1 #222 SMP PREEMPT Tue Jun 11 16:30:33 CEST 2019 armv7l
Mode: Gateway/Repeater
Reset: No
Uptime: ~1 hours
Status: Was seeing significantly slower speeds across repeated network. Downgraded to r40009 without reset and problem went away. _________________ https://benguild.com
Router/Version: Asus RT-AC3100
File: 2019-06-30_asus_rt-ac3100-firmware.trx
Kernel: Linux 4.4.181-rc1 #222 SMP PREEMPT Tue Jun 11 16:30:33 CEST 2019 armv7l
Mode: Gateway/Repeater
Reset: No
Uptime: ~1 hours
Status: Was seeing significantly slower speeds across repeated network. Downgraded to r40009 without reset and problem went away. _________________ https://benguild.com
Joined: 08 May 2018 Posts: 14222 Location: Texas, USA
Posted: Thu Jul 04, 2019 14:20 Post subject:
denislen wrote:
40065 works great for asus rt-n10u b1
still no usb flash support
No ext2, ext3, ext4 filesystem support, but I am willing to wager that there is fat and ms-dos filesystem support, and possibly ntfs. Only way to add ext* filesystem support is to lose another feature or package or something. Not a new issue:
What is the Network paramenters "TX Queue Length" for actually? Does it improve anything if I modify "TX Queue Length" for eth and vlan?
I sent you a pm.
Back to topic, I am trying to think of what may have caused my brick other than a bad flash OR the threading changes to httpd OR something else. I have another test unit I can check with, it's already serial recovery ready.
EDIT: Looks like perhaps the problem was fixed and should be good in next build https://svn.dd-wrt.com/changeset/40182. However, the actual problem for N-devices with dual band is that the default vlan settings and some other things are incorrect and haven't been fixed in public betas, but I have no GLUE I guess if I were to reset to defaults or try flashing this build on the test bench unit and not touch the vlans page whatsoever, if might be fine
