Rpi4 < $(community_build)

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
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdc4:432c:9b11::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0'
	option proto 'static'
	option ipaddr '10.83.66.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ip6weight '1'

config interface 'WAN'
	option proto 'dhcp'
	option ifname 'eth1'

config interface 'WAN6'
	option proto 'dhcpv6'
	option ifname 'eth1'
	option reqprefix 'auto'

1 Like

Holy... I discovered something. After testing wireguard, I disabled it and did a speedtest.

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.

Before: CPU0

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'...

thanks for the report... i'm pretty stumped by the log... you could start removing any opkg packages that are called '6' something one by one...

the other thing we can do if you are really interested in getting to the bottom of it... is

  1. test your config on a par for par ( current ) master... to eliminate anything mainline quickly... then

  2. I can build you the smaller 'std' variant with less packages... and you can then start uninstalling stuff if needed...

if you did not mention official was rock solid I would say it's probably not build specfic or at least... its very config/(isp connection) specific...

but I really have no idea what to say on that one... sorry...

never seen this before... ( maybe my ipv6 skills need some miyagi-san action ) what does it do? turn some sysctl knobs to prefer ipv6 or something?

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.

Additionally, I do not know either what ip6weight is but please let me point out there is actually much changing in what options are exposed from luci to this file. The option was not inserted from me manually.
See for reference this thread from me: [Solved] LAN clients no IPv6 (ra_mtu option in /etc/config/dhcp causes problems) - Installing and Using OpenWrt / Network and Wireless Configuration - OpenWrt Forum. Also obey the reference to a similair thread in it.

May be additional users show up with such an issue...

1 Like

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 :slight_smile:

1 Like

glad the build has been of use to you...

no need... perfectly valid question...

the best way is to;

  • add any extra files you have not added yet to sysupgrade.conf@luci>system>backup>configuration
  • upgrade to the lastest (community) build to get the gui backup feature
  • use the backup feature provided
  • download the file
  • 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)

1 Like

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! :slight_smile:

1 Like

a few new options in the next build...

  1. optional boot time smb mounting (no(ini)backport)
all options need to be specified
#SMBUSER="john"
#SMBPASSWD="smith"
#SMBUID="1000"
#SMBSERVER="10.2.3.6"
#SMBSHARE="downloads"
#SMBMNTPNT="/usbstick/downloads"

  1. opkg proto selection ((ini)backport - comment it out if you prefer https)
OPKGFEEDS_USEHTTP=1

  1. www/dl youtube download interface (no(ini)backport - very beta no auth as yet... anyone good at php?)
# YOUTUBEDL="/usbstick/downloads" #NOTE for now you must use this path and mount a usb drive or smb share to it


  1. advanced users: boot-time rmmod (no(ini)backport)
#RMMOD="snd_bcm2835 snd_compress snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm_dmaengine snd_rawmidi snd_pcm snd_seq_device snd_timer snd soundcore rndis_host pl2303 ums_freecom ums_alauda iscsi_tcp libiscsi_tcp dm9601 ums_jumpshot ums_karma usb_f_ecm u_ether sch_pie sch_red xt_cgroup xt_pkttype xt_owner sch_gred sch_teql ums_isd200 ums_datafab sch_hfsc sch_htb sch_tbf"

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.

As an FYI, there is a new stable eeprom update out now for the RPi4 (March 18, 2021):

2 Likes

Just curious what's the current status/timeline for official build (moving away from snapshot)?

1 Like

I have a question: is there a chance to get jumbo frames on the onboard nic?

1 Like

http://lists.openwrt.org/pipermail/openwrt-devel/2021-April/034866.html

https://downloads.openwrt.org/releases/21.02.0-rc1/targets/bcm27xx/bcm2711

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...

1 Like

are you going to build image using 21.01 for pi4?

1 Like

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
  1. now they are virtually identical... so it's primarily for the use of providing upstream testing for the rc phase... (and build compatibility handling)

  2. 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...

1 Like

so I tried nicmove and mac-match and proceeded to brick the Pi.

I had an old apple A1277 100mb dongle lying around so put that and a realtek into a powered USB3 hub. Works for me as ISP2 is less than 100mb

That has kept the same eth1 and eth2 assignment through multiple reboots.

I needed to load kmod-usb-net-asix-ax88179 to make it work. Can I suggest to include in the build?

Now ordering gb USB3 dongles with chipset AX88179 made by UGREEN.

100mb adapters are based upon ASIX AX88772 chipsets.

Will post back in about 10 days how many dongles I can get working on a powered hub..

1 Like