I noticed that maybe 1-2 months ago occasionally with WNDR3700, but so rarely that I did not look into it. Now it seems to be more frequent with the recent sysupgrade changes.
I perfectly managed to update today editing the file /lib/upgrade/stage2 replacing
"install_file /etc/resolv.conf /lib/.sh /lib/functions/.sh /lib/upgrade/.sh /lib/upgrade/do_stage2 $RAMFS_COPY_DATA"* with "install_file /etc/resolv.conf /lib/.sh /lib/functions/.sh /lib/upgrade/.sh /lib/upgrade/do_stage2 /usr/share/libubox/jshn.sh $RAMFS_COPY_DATA"*
and using the builds WNDR3700v2-master-r11558-3cee6f3f24-20191120-1926-sqfs-sysupgrade.bin (ath79-master) and WNDR3700-master-r11546-a74095c68c-20191119-1953-sqfs-sysupgrade.bin (ar71xx-master)
Thank you!
Hi hnyman,
I've tried to use your build scripts to do my own builds. But it seems that they are outdated. I managed to update the source files doing some fixes to paths in your scripts, but I've failed compiling them:
...make the firmware...
...create version info file...
hnscripts/timestampVersion.sh: line 8: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 9: files/etc/Compile_info.txt: No such file or directory
fatal: not a git repository (or any of the parent directories): .git
hnscripts/timestampVersion.sh: line 10: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 11: cd: feeds/luci: No such file or directory
hnscripts/timestampVersion.sh: line 11: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 12: cd: feeds/packages: No such file or directory
hnscripts/timestampVersion.sh: line 12: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 13: cd: feeds/routing: No such file or directory
hnscripts/timestampVersion.sh: line 13: files/etc/Compile_info.txt: No such file or directory
cat: files/etc/Compile_info.txt: No such file or directory
fatal: not a git repository (or any of the parent directories): .git
...make world...
I've called the updateNmake.sh from the parent folder as suggested in the readme. But it seems that the paths do not fit anymore. files/etc has moved to master/package/base-files/files/etc ? But from searching .../files/etc there seem to be some more options...
It would be great, if you could update the build scripts. Many thanks in advance!
BR. - nieroster
The current build scripts are included with each build I publish.
And nothing has moved to basefiles...
Sorry to bother you. There were a few misunderstandings. First I forgot the patch files, 2nd I used the general build scripts you have in your dropbox, not the ones for the specific build (ar71xx-master). I saw there is a hnscripts folder within master too. After changing to master and calling the build script from there everything worked like a charm!
Thank you again for your great work!
ar71xx-master-r11827-f8424b1b26-20191228
The recent ubus version upgrade two days ago caused a bug for system log, which bug has now been fixed. However, the change also caused some services not to start, e.g. collectd (= LuCI statistics) and nlbwmon. ldir figured out that those fail where the procd init file has a "nice" parameter definition:
I have implemented that workaround in my own build.
Hopefully the underlying bug (in ubus or procd) gets fixed, but until then the workaround is to have the nice definition before the command definition in the procd init file of a service. (Note that the bug may affect also other packages/services that define "nice", but those two are the main affected ones in my build.)
EDIT:
ath79-master-r11829-e3e939d8e6-20191228
The bug (that was in blobmsg handling in libubox) has been fixed.
One thing I've noticed with your latest ath79 builds: After the first hard reboot the WiFi LEDs seem to be messed up on my WNDR3700v2/WNDR3800. When deactivating the 5G network the green LED is off and vice versa. Can this be a settings issue?
It is an intermittent symptom. I noticed that already when I authored the wifi support for WNDR3700 in ath79 in August 2018:
https://github.com/openwrt/openwrt/pull/1284
Known issues:
...
phy0 and phy1 may get assigned mixed, so that phy0 may be the 5GHz radio instead of the normal 2.4GHz, and vice versa for phy1. Does not happen always, but may happen.
In build ar71xx-master-r11968-3446702cdb-20200113/WNDR3800 Internet acces does not work because of name resolution not working anymore. Do you have the same problem?
My current WNDR3700 build is in my secondary router, so I haven't really tested full connectivity with DNS.
But I would guess that your troubles are related to recent changes in dnsmasq resolv file location and e.g. a restored config (after the transisition script had already run):
4 days ago Daniel Golle dnsmasq: add uci-defaults script for config migration
6 days ago |Daniel Golle| dnsmasq: switch to /tmp/resolv.conf.d/resolv.conf.auto
6 days ago |Daniel Golle| netifd: move /tmp/resolv.conf.auto to /tmp/resolv.conf.d/
6 days ago |Daniel Golle| base-files: move /tmp/resolv.conf.auto to /tmp/resolv...
That same change may cause me trouble when jumping back to 19.07 from master, but I have not had time to look into possible mitigations (like creating the same dir also in 19.07)
In fact I did keep the settings which worked fine so far. I'll have a look.
owrt1907-r10874-455ba76bf9-20200116
A week ago a change was made in master that changed the default position of resolv.conf.auto file (for DNS).
There is a transition script in master and most users will never see any problem when sysupgrading. (But if you restore an older config to the current master, you might hit trouble.)
The same goes for downgrading from master to 19.07, as the new default is a new directory instead of a plain file. So I added a reverse transition script to my 19.07 build, so that I am still able to seamlessy jump back to 19.07 with my builds.
I don't know what the exact process is when you kepp settings. Are they overridden and restored or do they stay in place?
I could not get dnsmasq running if I keep my settings during update, not even if I create the folder you mentioned. What I was wondering is: why can't dnsmasq create the temp files it uses including it's parent folder? Doesn't have to do this anyway when you restart the router?
If I reset the router to default settings it seems to work, but I am not ready to re-enter the complete configuration again through the webinterface. I even tried to restore the dhcp config file from a default settings backup, but this did not work either.
The transition script does not seem to work in my case. I am currently using the ar71xx-master build.
If you have looked at the commits that I referenced, you may have noticed that it is actually "base-files" that creates the directory that dnsmasq currently uses.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=fedc5d30ae0a39a7d308adae8ed918dc5b603067
The config files are copied to a temporary file in RAM and flashed after the end of the flashed firmware image. During the first boot, the settings archive is noticed and expanded to overlay. Then a bit later in the boot process the uci-defaults scripts (like the transition script I mentioned) are run, and the restored settings can be manipulated buy them.
Apparently something in your config is strange. But without seeing your settings, it is hard to guess what...
I do not know if something is strange with my config or if the transition script simply isn't in place. Where should I find it?
In live router /etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh (befoer the first boot after flashing),
and after that it can only be seen in /rom:
/rom/etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r12040-8df14c229c
-----------------------------------------------------
root@router1:~#
root@router1:~# cat /etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh
cat: can't open '/etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh': No such file or directory
root@router1:~#
root@router1:~#
root@router1:~# cat /rom/etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh
#!/bin/sh
[ "$(uci get dhcp.@dnsmasq[0].resolvfile)" = "/tmp/resolv.conf.auto" ] && {
uci set dhcp.@dnsmasq[0].resolvfile="/tmp/resolv.conf.d/resolv.conf.auto"
uci commit dhcp
}
root@router1:~#
root@router1:~#
The point is that you run into trouble if your dnsmasq settings point to a directory that does not exist.
But as this has nothing specific to do with my build, as if was a generic OpenWrt change, you might open an own thread if your settings need more debugging.
I did play around with dnsmasq again. What was missing is the first line in /etc/init.d/boot, the others I had to modify:
mkdir -p /tmp/resolv.conf.d
touch /tmp/resolv.conf.d/resolv.conf.auto
ln -sf /tmp/resolv.conf.d/resolv.conf.auto /tmp/resolv.conf
and then I had to add in /etc/config/dhcp which was missing completely for some reason:
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
I updated from ar71xx to ath79 and everything seems to work well, but in Chrome (both desktop and mobile) I get "ERR_SSL_KEY_USAGE_INCOMPATIBLE". In Firefox I get a warning about the certificate but I can override it. Chrome usually allows to override the warning (both on mobile and desktop), but not this time.
I repeated the procedure indicated in https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings after deleting the old one from my desktop, but it doesn't seem to work neither in Firefox nor in Chrome.
Has anything changed in the new build related to openssl and uhttpd? If not and if you have no idea, I'll go to the normal OpenWRT forum to ask for help.
Nothing has changed in OpenWRT, it simply uses a self signed certificate. But web-browsers tend to get more strict every now and then.
I have installed acme which gets you a Let's Encrypt certificate and made an entry to the hosts file pointing to the LAN address of the router: 192.x.x.x my.routers.domain
Of course you need a ddns service too to resolve your external address to a name (my.routers.domain)
I noticed that the ath9 builds limit the internet throughput considerably. While I get up to 244Mbit/s from the ar71 builds (which is close to the theoretical maximum of my internet connection) the ath9 builds limit the throughput to about 150Mbit/s. When opening the webgui it slows down even more (< 100Mbit/s).
Did anybody else notice this too?