Notes: 1. SFE accelerated NAT is in 33006+ builds but only in kernel 3.10 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 Issue #4 below).
4.R6400v2 support added in r36811-36818, 36825, and 36826. R6700v3 support added in r36828-36840.
Issues, observations, and/or workarounds reported: 1. (egc) Policy-Based Routing broken if SFE enabled: 5900 quarkysg's PBR+SFE fix: 5986 2.Trendnet 81*DRU models are missing factory-to-flash 3.DNScrypt is mostly only using v2 protocols now, but requires Golang that DD can't use:6246 4.WDS does not work on ARM devices (only MIPS<->MIPS) 5.VAPs not working at boot; workaround startup command:
sleep 10;stopservice nas;stopservice wlconf;startservice wlconf;startservice nas
6.K2.6 builds are broken since 38253(?); GUI issues:6538 7.High CPU usage (on httpd?) occurring for some configurations:6555 Try `stopservice httpd` from ssh/telnet and report back. To flash another build, stop httpd and use CLI flash.
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. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Router/Version: Asus RT-N18U Firmware: DD-WRT v3.0-r39290 std (03/26/19) Kernel: Linux 4.4.177 #5278 Tue Mar 26 11:38:55 CET 2019 armv7l Mode: Gateway/AP File: asuslog.txt Status: Mostly Usable, Advanced WLAN configurations not working correctly (Works Correctly on r34411)
### Configurations Present:
Networking TAB:
br0 - Default Bridge
>>> VLAN 1 / WL0 (Ports 1 and 2 From the switch)
br1 - Secondary bridge for separate network
>>> VLAN 5 / WL0.1 (Port 3 from the switch)
br2 - Third bridge for another separate network
>>> VLAN 6 / WL0.2 (Port 4 from the switch)
### VLANs Tab:
Switch port 1/2: VLAN 1
Switch port 3: VLAN 5
Switch port 4: VLAN 6
### Wireless Tab:
WL0 - Main network, using default bridge (br0)
WL0.1 - using secondary bridge (br1), selected "bridged" on "Network Configuration"
WL0.2 - using secondary bridge (br2), selected "bridged" on "Network Configuration"
The VAP fix does not work for me, running from the command line or telnet.
For testing purposes, i did not enable NET isolation, as well as a set of another rules i have created to suit my testing needs (mainly to avoid vlans contacting each other and/or the WAN subnet).
Other useful information:
CPU and Memory usage seems normal after a few reboots;
Main WLAN works as expected, just the other ones are not working;
Encrypted DNS working as expected;
There are some cosmetic GUI issues, but it seems the GUI is under work at the moment.
Atatched is the DMESG Log from the router. I can provide any other info if necessary!
Sorry in advance if any info is missing or incorrectly presented. I read the rules, everything seems fine i think!
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r39290 std (03/26/19)
Kernel: Linux 4.4.177 #5274 SMP Tue Mar 26 11:10:26 CET 2019 armv7l
Previous: r39267
Mode/Status: Gateway / working
Reset: no
Issues/Errors: No issues so far.
Uptime: 1h 34m
Temperatures: CPU 68.6 °C / WL0 48.4 °C / WL1 54.0 °C
Joined: 08 May 2018 Posts: 16806 Location: Texas, USA
Posted: Wed Mar 27, 2019 2:15 Post subject: Cisco Linksys E4200 v1
Router/Version: Cisco Linksys E4200 v1
File: dd-wrt.v24-39290_NEWD-2_K3.x_mega-e4200.bin
Firmware: DD-WRT v3.0-r39290M mega (03/26/19)
Kernel: Linux 3.10.108-d8 #23696 Tue Mar 26 13:19:26 CET 2019 mips
Previous: DD-WRT v3.0-r39267M mega (03/22/19)
Reset: No
Mode: Gateway/AP
Uptime: ~7.5 hrs
Status: OK
Issues/Errors:
No new errors, but did have a hiccup with wireless resolution. Haven't seen any commits from upstream on dnsmasq, which may be a contributing factor. Did the re-select no reset on upgrade page, so not sure if that glitch is fixed or not. Guess I'll give it a whirl next time around.
Joined: 08 May 2018 Posts: 16806 Location: Texas, USA
Posted: Wed Mar 27, 2019 21:10 Post subject: Re: Cisco Linksys E4200 v1
kernel-panic69 wrote:
Router/Version: Cisco Linksys E4200 v1
File: dd-wrt.v24-39290_NEWD-2_K3.x_mega-e4200.bin
Firmware: DD-WRT v3.0-r39290M mega (03/26/19)
Kernel: Linux 3.10.108-d8 #23696 Tue Mar 26 13:19:26 CET 2019 mips
Previous: DD-WRT v3.0-r39267M mega (03/22/19)
Reset: No
Mode: Gateway/AP
Uptime: ~7.5 hrs
Status: OK
Issues/Errors:
No new errors, but did have a hiccup with wireless resolution. Haven't seen any commits from upstream on dnsmasq, which may be a contributing factor. Did the re-select no reset on upgrade page, so not sure if that glitch is fixed or not. Guess I'll give it a whirl next time around.
More new console messages:
Code:
wl 0000:00:01.0 eth1: (WE) : Wireless Event (cmd=0x8C02) too big (30150)
wl 0000:00:01.0 eth1: (WE) : Wireless Event (cmd=0x8C02) too big (30150)
Joined: 29 Nov 2013 Posts: 36 Location: Düsseldorf, Germany
Posted: Wed Mar 27, 2019 21:27 Post subject: ASUS RT-N66U
Router/Version: ASUS RT-N66U
File: dd-wrt.v24-39290_NEWD-2_K3.x-big-RT-N66U.trx
Kernel: 3.10.108-d8 #23692
Mode: Gateway with TOR and Privoxy
Status: Machines on WLANs are still partially isolated
Up for a few minus now, still some machines on the WLANs see each other, some don't.
Router/Version: Tplink Archer C1900
File: archer-c1900-webflash.bin
Kernel: 4.4.177
Mode: Gateway / AP
Status: Reset defaults after flashing and so far everything has been working great for the last 30 hours. I don't have a very complicated setup (No VPN or QoS)
Joined: 29 Nov 2013 Posts: 36 Location: Düsseldorf, Germany
Posted: Wed Apr 03, 2019 17:22 Post subject: Re: ASUS RT-N66U
knob-creek wrote:
Up for a few minus now, still some machines on the WLANs see each other, some don't.
Obviously, i do not follow the discussion here too closely.
Since the arbitrary forwarding (or not) within LAN & WLAN made the router almost unusable, i was just about to reset it and manually set it up again. This was when i stumbled over the SFE setting, which was (probably) on by default. But it is broken on Asus RT-N66U. After switching it off, i was able to connect all across the network, again.
Joined: 08 May 2018 Posts: 16806 Location: Texas, USA
Posted: Wed Apr 03, 2019 21:13 Post subject: Re: ASUS RT-N66U
knob-creek wrote:
knob-creek wrote:
Up for a few minus now, still some machines on the WLANs see each other, some don't.
Obviously, i do not follow the discussion here too closely.
Since the arbitrary forwarding (or not) within LAN & WLAN made the router almost unusable, i was just about to reset it and manually set it up again. This was when i stumbled over the SFE setting, which was (probably) on by default. But it is broken on Asus RT-N66U. After switching it off, i was able to connect all across the network, again.
This makes sense. SFE is not a Broadcom-specific mechanism, and I believe it was ported from Atheros (even though it's 'vanilla'?) and there's obviously some issues with Broadcom hardware using it. I'd have to compare upstream code. Also have to dig into ctf, igs, emf ... which I'm beginning to wonder if I missed deletion from the DD-WRT repository. ANYHOW, it seems that the issue that was allegedly "fixed" is not.
