Build for WNDR3700v1/v2 / WNDR3800


@hnyman you were right! The execution environment is set up differently. Executing from the terminal window the $PATH variable resolves to /usr/sbin:/usr/bin:/sbin:/bin. Executing from the custom commands page of the webinterface the $PATH variable is different: /sbin:/usr/sbin:/bin:/usr/bin.

Why is this set up differently?




Has anyone experiences with adblock? How many entries are too many for the V2? I'm using the standard build, no extras.



500 Internal Server Error

Sorry, the server encountered an unexpected error.

Failed to execute arcombine dispatcher target for entry '/admin/network/network'. The called action terminated with an exception: /usr/lib/lua/luci/template.lua:74: Failed to load template 'cbi/map'. Error while parsing template '/usr/lib/lua/luci/view/cbi/map.htm': Syntax error in /usr/lib/lua/luci/view/cbi/map.htm:24: unexpected symbol near ')' stack traceback: [C]: in function 'error' /usr/lib/lua/luci/template.lua:74: in function 'init' /usr/lib/lua/luci/util.lua:65: in function 'Template' /usr/lib/lua/luci/template.lua:27: in function 'render' /usr/lib/lua/luci/cbi.lua:257: in function 'render' /usr/lib/lua/luci/cbi.lua:440: in function 'render' /usr/lib/lua/luci/dispatcher.lua:945: in function 'target' /usr/lib/lua/luci/dispatcher.lua:981: in function

Powered by LuCI Master (git-18.344.63700-36f2265) / OpenWrt SNAPSHOT r8684-f6e9f23771



There have been intermittent issues like that recently, I'm quite sure they'll disappear if you update to a (more-) current snapshot as they should be fixed by now (while your commit id is around the breakage point).



Looks like the map error in Luci, which bug got introduced and also fixed a few days ago, but is still in that build you are using.

Next build should be ok again.

You could also manually edit the file right now. It is a one character fix to /usr/lib/lua/luci/view/cbi/map.htm (see the linked commit)

Or you can opkg install the updated luci-base from snapshot repo.

Ps. I will likely compile a new version today.



Todays build fixes the issue. Tank you!




First build with openssl 1.1.1a (instead of the 1.0.2 series...)
The new openssl version is somewhat larger than the old one, so the firmware size probably starts to be rather near max.limits in a 3700v1. I might need to try cutting some further packages from v1, if free space gets too small.



it still seems ok:

BusyBox v1.30.0 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 OpenWrt SNAPSHOT, r9330-880f8e6d32
root@OpenWRT:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.5M      5.5M         0 100% /rom
tmpfs                    29.1M      1.6M     27.5M   5% /tmp
/dev/mtdblock5          704.0K    364.0K    340.0K  52% /overlay
overlayfs:/overlay      704.0K    364.0K    340.0K  52% /
tmpfs                   512.0K         0    512.0K   0% /dev



I made a new ath79 test build and included the patch for speedying up the eeprom firmware extraction from Pilot6 (and being tested by chunkeey's staging tree) . That enables for the first time a functioning wifi right after the flashing. No need for a separate reboot for getting wifi to work.



This sounds great! But I have a question, would you recommend to switch over the the ath79 builds already or are the older master-build still recommended? I know that with master builds I volunteer to participate in bug-finding and debugging (although I have not been bitten by anything major for at least a year, thanks for your great builds and OpenWrt's robust master tree), so I am fine with that, I just wonder at what point will ath79 become the new normal?

Again thanks for your great builds, making it easy to test and follow master.



After this fix there is not much difference in practice.

There is still one MAC-address related quirk, as the old ar71xx has a special logic for modifying one of the MAC address stored in WNDR3700 art to be unique, and in ath79 that is not handled in DTS but requires a user-space script as in

I made a DTS based fix for that as, but it was rejected by @mkresin

I am considering re-introducing that PR, as a DTS based thing would be more reliable (as currently the new MAC is just stored in uci config). A rather similar DTS extension thing has been later done by nbd by , so adding this kind of OpenWrt-specifc fixes for DTS logic seem not to be quite that forbidden, after all.



Great, so I will just take the plunge on the next update and switch over to the ath79 builds.



I am only building ath79 more rarely, but feel free to test it.

Note that you have to force sysupgrade (both ar71xx-->ath79 and ath79-->ar71xx). Works both from LuCI and from SSH cnosole.

(Config is compatible but the firmware ID strings are different, so sysupgrade wants additional confirmation)



There will be some config differences, e.g. the paths for the wlan cards.



I have found another strange thing using a guest WIFI and VLANs:
Although connected to the guest WIFI (172.16...) I can access the routers web gui which is in a different network (192.168...). I've configured uhttpd to only listen to the lan IP (192.168...), I already set up a firewall rule to drop packets from the guest_lan with a destination of the lan zone: without any effect!

How can I effectively prevent web-administration from a different VLAN?



I've managed to do what I wanted to, but only with a firewall rule using the IP range of the guest network and the IP of the router uhttpd is listening to. A rule with the zones alone did not work for some reason. Does anybody know why?



aonther issue: openvpn does not start anymore.

BusyBox v1.30.1 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 OpenWrt SNAPSHOT, r9547-364ab348dc
root@OpenWRT:~# openvpn start_service
Error relocating /usr/sbin/openvpn: ENGINE_get_id: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_get_first: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_get_name: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_load_builtin_engines: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_set_default: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_free: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_register_all_complete: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_by_id: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_ctrl_cmd_string: symbol not found
Error relocating /usr/sbin/openvpn: ENGINE_get_next: symbol not found

I have reverted to build r9480, reinstalled openvpn and it still did not work.
Then I uploaded a backup and openvpn runs again.

Seems that something is wrong with the current openvpn-openssl in the repository.



So finally switched over, so far all seems to be as expected, so far so good...




The devs have committed a few minutes ago a change in openssl, so that it will have the engine support on by default (matching the current de-facto status in buildbot forced by some other packages).

So, my future builds (20190417 and later, in master) will have that config symbol on, and the engine related problems should then disappear.

master-r9880-bd3a18bbe4-20190418 and later buils

1 Like


@hnyman thanks a lot for your effort!
It's working again!