@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?
nieroster
Has anyone experiences with adblock? How many entries are too many for the V2? I'm using the standard build, no extras.
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.
https://github.com/openwrt/luci/commit/62990e23382943a30a2ac9520690b22dc07c90f2
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!
master-r9330-880f8e6d32-20190213
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
root@OpenWRT:~#
ath79-master-20190302
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 https://github.com/openwrt/openwrt/commit/437e35f8a3988cadf8797354e78cce3696b90916
I made a DTS based fix for that as https://github.com/openwrt/openwrt/pull/1257, 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 https://github.com/openwrt/openwrt/commit/a1f4ebcc874f8414ef551d653363eb0ef95d553c , 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
root@OpenWRT:~#
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...
Thanks/Kiitos
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).
https://github.com/openwrt/openwrt/commit/450d44a8ead2217f8acf541a4eaa4ad560b3e5ac
So, my future builds (20190417 and later, in master) will have that config symbol on, and the engine related problems should then disappear.
EDIT:
master-r9880-bd3a18bbe4-20190418 and later buils