Since last summer I am running an official snapshot which was rockstable for months.
LAN is on ethernet WAN is connected via r8152 to a fibre modem (DHCP).
3 Days ago I tried this build. The ipv6 connectivity is very unstable, dies every couple of hours. I got the case the connection looks proper, my smartphone albeit has no ipv6 connectivity (anymore).
Then I got a couple of times the WAN6 interface has no IP addresses attached anymore.
Mon Apr 19 06:24:28 2021 daemon.notice netifd: WAN (5157): udhcpc: sending renew to 100.124.1.45
Mon Apr 19 06:24:28 2021 daemon.notice netifd: WAN (5157): udhcpc: lease of 100.116.248.208 obtained, lease time 3600
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /etc/hosts - 4 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/odhcpd - 1 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq-dhcp[22920]: read /etc/ethers - 0 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /etc/hosts - 4 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/odhcpd - 1 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq-dhcp[22920]: read /etc/ethers - 0 addresses
Mon Apr 19 06:50:30 2021 daemon.warn odhcpd[2713]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Mon Apr 19 06:50:30 2021 daemon.warn odhcpd[2713]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Mon Apr 19 06:50:31 2021 daemon.debug dnsmasq[22920]: stopped listening on eth1(#12): 2a00:6020:1000:1f::37b8 port 53
Mon Apr 19 06:50:31 2021 daemon.debug dnsmasq[22920]: stopped listening on br-lan(#14): 2a00:6020:b2b7:a800::1 port 53
Mon Apr 19 06:50:32 2021 daemon.warn odhcpd[2713]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Mon Apr 19 06:50:34 2021 daemon.notice netifd: Interface 'WAN6' has lost the connection
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain test
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain onion
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain localhost
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain local
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain invalid
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain bind
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain lan
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.44.50#53
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.45.50#53
Mon Apr 19 06:50:49 2021 daemon.notice netifd: Interface 'WAN6' is now up
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain test
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain onion
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain localhost
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain local
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain invalid
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain bind
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain lan
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.44.50#53
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.45.50#53
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 2a00:6020:100::1#53
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 2a00:6020:200::1#53
Mon Apr 19 06:50:49 2021 user.notice firewall: Reloading firewall due to ifup of WAN6 (eth1)
Mon Apr 19 06:50:50 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup of WAN6 (eth1)
Mon Apr 19 06:53:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 1/0 in 60 seconds
Mon Apr 19 06:54:28 2021 daemon.notice netifd: WAN (5157): udhcpc: sending renew to 100.124.1.45
Mon Apr 19 06:54:28 2021 daemon.notice netifd: WAN (5157): udhcpc: lease of 100.116.248.208 obtained, lease time 3600
Mon Apr 19 06:54:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 2/0 in 60 seconds
Mon Apr 19 06:55:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 3/0 in 60 seconds
Mon Apr 19 06:56:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 4/0 in 60 seconds
Mon Apr 19 06:57:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 5/0 in 60 seconds
Maybe you could explain to me what magic happened here. From using cpu0 exclusively to all cores just by adding a wireguard instance. That's the only thing I did, add a wireguard instance. Wow.
thanks... i've now removed most of the perftweaks.sh and 20-smp due to limited input...
( but is is good to see that you read the relavent notices and took the appropriate action of turning them off )
as for the 50Mb/s... some setup scripts setup sqm with this as a default if they detect sqm config is blank... they may have misdetected your setup and 'unconfigured'...
next time this occurs... double check 'uci show sqm'...
Dear wulfy23, I sadly have to point out I changed back to official snapshot. I had no time to debug/investigate this because I needed a stable, reliable router/gateway to do my home office work stuff. I am very sorry, otherwise I would debug anything to get this straight.
I will report here if such strange issues happen also with the official snapshot.
I had the strange feeling my ssh connections via ipv6 terminated more often then with my old snapshot (in this they stayed online connected for days) with the new snapshot also but I was fumbling a lot with the network, I have to reassure. From extern/WAN through the actual router into the LAN they are stable.
perfect... thankyou! yes... that is probably also what I would have done... thanks for getting back so quickly ( and again for the info about the potential issue )...
Hi all, apologies if this is not the right place to seek advice on this topic. Over the last almost full year, I have benefitted greatly from using wulfy23's community build for the Rpi4. When I first started using this build, there was no official build yet, and I spent lots of time configuring a bunch of settings and whatnot to get everything to work. I'm basically a complete beginner when it comes to these things, and because of that, I'm probably not going to be able to provide much useful feedback for these newer, more experimental builds. With that said, I'm writing to see if someone could help me figure out how to preserve my configurations, settings and all that while transitioning over to the openwrt official build. Will I be able to use the existing "flash firmware" on the community build or do I have to reflash the SD card? If the latter, what is the best way to preserve those configurations, themes, etc. in order to make the transition as seamless as possible? Thanks to everyone who has posted here and helped me learn openwrt on the rpi4 and special thanks to wulfy23 for making this all possible
flash a new official factory (remove sdcard and full flash)
boot the new factory image (at 192.168.1.1)
restore your backup (ip may change if different perhaps reboot)
so given the advice above... likely not...
for advanced users technically you could try 'sysupgrade -n -p -F newfactory.img'... but there will be automatic artifacts in installed_packages.txt... (which wouldn't be a direct problem)
Hi wulfy23, thank you so much for the prompt response, I really appreciate it! I'm planning to work on this sometime in the next week when I am able to take the home network down and will report back one way or another once I've tried. Thanks again!
Isn't the official build still snapshot, so doesn't have luci Gui etc installed, it won't have the drivers for ethernet to usb adapters preloaded... I'd stick with the community build for now, or compile you own if you just want the basics.
you'll need a buildroot for that based on a quick search ( scroll down to the graysky post )...
surprised that thread only had a handfull of posts...
either way... this build is created with the imagebuilder so leverages 1:1 official binaries. as a result (kernel/kmod) compile time mods are not an option.
consider creating a thread about this on the general forum...
good question... ( in the past few weeks i've put up a few 21.02-SNAPSHOT and 21.02.0-rc1 see point 1 below )
at the moment there are a few factors that govern this...
stability of current master
compatibility of master with build features
performance and or other benefits offered by master
online storage space
user demand
now they are virtually identical... so it's primarily for the use of providing upstream testing for the rc phase... (and build compatibility handling)
a point may likely arise where some sort of forking will be necessary for one or several build features and the build may switch to the stable release... for an indefinite period depending on how major the changes are...
feel free to grab on of the 21.02.0-rcX images the next time they are up...
good to do whilst they are relatively crosscompatible...
i've tested a few and added support for the majority of build features so they are relatively 'safe' to try out...