Rpi4 < $(community_build)

I getting issues in games. Connection interrupted with the server. Is it ISP issue or with openwrt build? I am getting these errors after the lastest build. And i also made some config changes. like adding dnssec in dnsmasq

	• Edit /etc/config/dhcp
In the config dnsmasq section, add (or change the values of, if these settings already exist) these settings:
		○ option dnssec '1'
		○ option dnsseccheckunsigned '1'
	• Restart dnsmasq so the changes take effect: /etc/init.d/dnsmasq restart

not too sure... I've also noticed some possible oddness ( browser debugger ... seems like something to do with dns or chatty connections or proto detection )... i.e. sometimes you open a browser window and it says 'address change detected' or something like that...

edit: chromium message is...

Your connection was interrupted
A network change was detected
ERR_NETWORK_CHANGED

than a second later the page loads... ( I did re-install both my debian host-os's tho' so could also be related to that I suppose )

I may have to upload an 'older' build... ( or two )...

maybe see if it goes away without sqm and masqsec changes first...

1 Like

turned off SQM and dnssec still name issue. Looks like issue from ISP side i guess. And i suspect it is with IP range. because after power loss i got IP from different IP range and it was working yesterday. But today IP from same IP range on which i faced the issue before

1 Like

Just a quick question, which RAM version of the PI is recommended(2/4/8)? Couldn't find anybody recommended one over the other. Will be setting up a PI for my gigabit connection.

2/4/8 are all fine ( personally running 2 )... 4/8 offer better long term repurposablility options...

Running just fine on a 2GB model...honestly I would have grabbed the 1GB version if it was readily available. OpenWRT is only reporting 147MB RAM used.

1 Like

While 1 GB RAM is plenty for OpenWrt (as a traditional router), there is no price difference between the 1 GB and 2 GB models anymore, so it doesn't make sense to buy the smaller one (even if you're unlikely to go beyond 1 GB RAM usage)

1 Like

I guess it depends on where you buy it...here in the US, Microcenter only stocks the 2GB model at $35 while at Adafruit the 1GB is $30 and the 2GB is $35.

interesting... UE305 > AX88179 ( assuming cheaper? )... yet they want $5AUD more... must be for the number 5 and black color scheme... ( admittedly these things are fairly well priced tho' )

Hey! I bought a Raspbery Pi 4 and tried flashing it with this version of OpenWRT, that's my first raspbery pi, and first openwrt device, so I'm a bit clueless

I also bought a ethernet-usb adapter so I can connect to openVPN/PPPoE and then send that connection to my router (Which has bigger antennas!), but it didn't arrive yet, so I was trying to set up the raspbery pi to connect via wireless just to test the openVPN stuff (The reason why I bought it to use as a router in first place), so, while the cable doesn't arrive, I'm trying to see if I can connect and test and it's everything alright within my window of time to send it back if it arrived with any problems.

So, what I'm trying for now is to either connect the RPi4 to the current wi-fi and see if I can use openVPN on the ethernet port or create a wireless connection so I can connect to the ISP via cable and test the OpenVPN via wireless close to it. But I can't manage to make it connect to wireless neither as client nor to make it serve a connection via wireless, it says it's not associated

using SSH and /sbin/wifi config don't give any error or message, just does nothing...
What should I do?

I've reflashed the SD card with the newest version from github, but it still has the same problem, I've also noticed it says that the network device is not present:

I've tried to change configs in /etc/config/wireless a lot of times and tried using wifi config a lot of times too, but none of the changes made it work.

I've noticed that it's giving me an "eth1" not found error over and over on the logs:
2021 daemon.err collectd[22276]: exec plugin: exec_read_one: error = Cannot find device "eth1"

Noticed that time and date are wrong too (And I don't know how to change it ^^')
EDIT: Nevermind, found how to change time

What else can I do to help debugging it?

Wireless on Raspberry Pi 4 won't work until you set the country code, which cannot be done in OpenWRT. You must flash the SD card first with Raspbian. Boot from Raspian and then run Raspi-Config from the command line. Select the menu option to set locale settings and wireless settings. Set your Wireless Country Code. Once you do that, wireless should start to work once you are back in OpenWRT.

For more details, see post 551 in this thread, above.

2 Likes

Thanks, that did it, I managed to install raspbian (without desktop environment), configure with raspi-config and then reflashed the sd card with the other version of the raspberry pi openwrt, after enabling the wireless in the config, wifi config and wifi up still returned no message, but when I rebooted the device, it connected to my router and then I was able to install Luci and other packages.
Was it supposed not to show anything and only work after a reboot, or is it just some other oddity of Raspberry Pi's radio?

Been there, done that. In my case I was only able to make it work after doing the country code thing in Raspian AND replacing WPAD with HOSTAPD. Don't quite know the exact reason why the latter was able to work, while the former was not...

could you please, explain a step by step how to do it, sir...
I'm using raspberry pi 4b with argon one case either..
I can't follow your explanation, because I'm just noob..
I need to switch my fan "Always On"
thanks before

1 Like

edit: nope that was for 'poe-fan' (module?)I think for always on you can just install a single package -> search for 'fan' in opkg

or you can try the unfinished installer script... ( enter this line into luci > system > commands > docmd with single quotes ( ' ) around it then click run if you cannot use a command line then reboot )

ARGONONEENABLE=1 /etc/custom/firstboot/4-model-b/25-dtbomods

ADVANCED USERS EXPERIMENTAL 21.02-SNAPSHOT

There is now an experimental 21.02-SNAPSHOT image at github... ( sysup only )

verbage
  • mostly for a consistent 'compare run' against ongoing master changes
  • don't know how long it will be up for... probably for as long as master + 21.02 are reasonably compatible then we will have to re-assess
  • its a work in progress so advanced build features/scripts function are likely to be buggy for sometime... ( i've tested sysupgrade to and from... and typical stuff seems ok... have not really tested installing packages... just a simple update )

( although it's early days... 21.02 seems to have some ~minimal~ additional baseline cpu/utilization overheads compared to master... so perma-adopting seems unlikely in it's current form [iproute2?])


POSSIBLE RRD ISSUE

  • ran into an issue with luci statistics... no idea where it came from ( probably malfunction/badtiming of the backup script )... but keep an eye out for 'is not an RRD file x 300' in logread... something like this gets it running again
intervention
rm -rf /tmp/rrd/rpi-dca6325631/processes*
rm -rf /tmp/rrd/rpi-dca6325631/sqm*
rm -rf /tmp/rrd/rpi-dca6325631/thermal-thermal_zone0/
/etc/init.d/luci_statistics restart
logread

(edit: saw a post recently where this was a known thing? and there may be a possible data-format migration script floating around the forum somewhere)


OPKG REPO FLUSH - OPENSSL FIX

opkg repo's are full and there is an openssl fix (1.1.1k) in the next build... so will likely flush the opkg repo's within the week...

verbage

anyone wishing to 'stay' on an older build and thinking they may need kmods||core||base||luci packages should probably make a local clone...

moving forward... there will likely be less space ( due to 21.02 and the pace of master )... so this is also recommended from here on in... ( so I don't have to keep posting about it )...

r15731-dba76a85de
r15871-bb817bb4b8
r15880-8d8125a43b
r15963-512229ce49
r16076-5a3562cd1d
r16121-20b6e014a6
r16310-bc356de285
r16323-5053593e66
2 Likes

I have a suggestion about better core usage: Can we load balance cores more efficiently? - #35 by dl12345

Beside that, nice build!

1 Like

good suggestion... thanks...

EDIT:
21st/April > now mostly disabled due to limited input

verbage

messed around a bit with steering / affinity mods... the build has the underlying code to implement these... but the combo of the bcm architecture and the way my brain is unable to comprehend numbers / calcs left me scratching my head...

from memory... with some 'settings' one things was alot better... and another was slightly worse ( up/down latency/goodput )
( there is definitely something glued between eth0+core+ticks in other words eth0 is picky )

being down under my bandwidth ain't exactly stress material either 50/15 ( making the build the pi has been in production use... ( 3 incidents )... ) so ripping it out to really stress the thing is a few day exercise...

was daydreaming today about what impacts 500+ really have on the thing...

basically anyone who has some optimal values / code by all means... post it... everyone can test!/contribute

peeps run different wan eth chipsets and they behave differently... ( so would be good to try to separate the tweaks as such )


build-perftweaks-info

edit : newer instructions / notes

i've hacked up most of the functions to 'beta-work' in /bin/rpi-perftweaks.sh for the next revision... set PERFTWEAKS=1 in wrt.ini then edit / mess with the file to your hearts content...(after you test defaults) and report back any good values that seem to help... left off the packets steering logic but i'm pretty sure there are some scraps at the bottom of the file to work off if you are game...

a good simple test is to;

  • leave the PERFTWEAKS off/commented out or do so and reboot
  • disable sqm
  • run a speed test && check /proc/interripts || htop cpu pinning etc. etc.
  • run 'PERFTWEAKS=1 /bin/rpi-perftweaks.sh
  • rerun you speed test and checks to compare with the default values

there are;

  • GOVERNOR~FREQ
  • IRQ-AFFINITY
  • TASKSET
  • RENICE
  • IRQBALANCE (ignore this for now)

at your disposal... TASKSET, STEERING and AFFINITY are the main ones that require / offer the most results... but they interact... so try to only mess with one at a time...

1 Like

2.9.17-2 (r16357+)

note1: finding modern dns way too chatty... so setting min_cache_ttl... advanced users may wish to disable this or experiment and report back with alternate values or ideas to reduce requery chatter...

note2: new installs (fac) also recieve PERFTWEAKS=1 ... ( not backported )... it's experimental at this stage so some may wish to disable... some may wish to enable...

edit-this-temporarily-overrides-existing-single-values
# POWERPROFILE="quicker"                     # default quick quicker quickest reduced
# IRQMANAGEMENT="irqbalance"                 # irqbalance non

note3: fyi, anyone updating from a recent build if your pi is not in a case may notice a few 'states' that the led flashing goes through while updating / firstbooting...

(edit: also some minor tweaks to htoprc )

2 Likes