Rpi4 < $(community_build)

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

Heya, newish to openwrt...moving over from dd-wrt. I have an rpi4 and have flashed rpi4.64-snapshot-25762-2.7.136-3-r16310-ext4-fac.img.

It starts up and runs fine, I've gotten it all tweaked the way I want (turned of ipv6, input all my static leases, etc). However, as soon as I reboot it, it stops handing out dhcp leases. My static ip computers work fine, but nothing is able to get a dhcp lease. The router has connectivity via the wan, but just stops giving out leases as far as I can tell. Dnsmasq is running (per the logs), normally, and restarting it doesn't seem to help.

I can't find any obvious problems in the logs though I do keep getting "unknown qdisc type 'fq_codel' on interface 'eth1'". Not a long of obvious other networking issues. Looking back through this topic, the error above doesn't seem like it should explain what is happening.

If I reflash the card, and restore from a backup everything works again, until I reboot. Is there something basic I am missing here? Happy to provide full logs, etc.

Thanks for any assistance....

1 Like

welcome to the community... and thanks for a well thought out and detailed breakdown of your issue/actions/symptomatology

post the output of 'uci show dhcp' from an ssh terminal
( or paste it into system > commands > docmd and click run )

within code tags ( </> at the top of the posting window )
( change any mac addresses to something random )

thats pretty odd... and seems to point towards either something unusual with your network settings or something custom in the dnsmasq config (probably to do with addresses)... ( or possibly another dhcp server? )

if you restore a backup from a non-same version... and don't edit cmdline.txt with the current PARTUUID then the pi will fail to boot. ( did the static clients work after you rebooted after restore? )

you can edit the cmdline.txt in a windows computer... if your using mmc then change it back to;

root=/dev/mmcblk0p2

and any future backups / restores ( from those backups ) should work correctly...

1 Like

Here is my "uci show dhcp".

dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].localservice='1'
dhcp.@dnsmasq[0].ednspacket_max='1232'
dhcp.@dnsmasq[0].dnsforwardmax='1500'
dhcp.@dnsmasq[0].cachesize='5000'
dhcp.@dnsmasq[0].confdir='/tmp/dnsmasq.d'
dhcp.@dnsmasq[0].dnssec='1'
dhcp.@dnsmasq[0].noresolv='1'
dhcp.@dnsmasq[0].server='127.0.0.1#5453'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.limit='150'
dhcp.lan.leasetime='12h'
dhcp.lan.dhcpv4='server'
dhcp.lan.ra_slaac='1'
dhcp.lan.ra_flags='managed-config' 'other-config'
dhcp.lan.start='200'
dhcp.lan.dhcp_option='6, 208.67.222.222, 208.67.220.220'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'
dhcp.odhcpd=odhcpd
dhcp.odhcpd.maindhcp='0'
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.leasetrigger='/usr/sbin/odhcpd-update'
dhcp.odhcpd.loglevel='4'
dhcp.@host[0]=host
dhcp.@host[0].name='livingroomheatpump'
dhcp.@host[0].dns='1'
dhcp.@host[0].mac='
dhcp.@host[0].ip='
dhcp.@host[0].leasetime='infinite'
dhcp.@host[1]=host
dhcp.@host[1].name='hasshost'
dhcp.@host[1].dns='1'
dhcp.@host[1].mac='
dhcp.@host[1].ip='
dhcp.@host[1].leasetime='infinite'
dhcp.@host[2]=host
dhcp.@host[2].name='willheatpump'
dhcp.@host[2].dns='1'
dhcp.@host[2].mac=
dhcp.@host[2].ip='
dhcp.@host[2].leasetime='infinite'
dhcp.@host[3]=host
dhcp.@host[3].name='maxeliheatpump'
dhcp.@host[3].dns='1'
dhcp.@host[3].mac='
dhcp.@host[3].ip='
dhcp.@host[3].leasetime='infinite'
dhcp.@host[4]=host
dhcp.@host[4].name='masterbedroomheatpump'
dhcp.@host[4].dns='1'
dhcp.@host[4].mac=
dhcp.@host[4].ip='
dhcp.@host[4].leasetime='infinite'
dhcp.@host[5]=host
dhcp.@host[5].name='ted-server'
dhcp.@host[5].dns='1'
dhcp.@host[5].mac=
dhcp.@host[5].ip='
dhcp.@host[5].leasetime='infinite'
dhcp.@host[6]=host
dhcp.@host[6].name='blinkhub'
dhcp.@host[6].dns='1'
dhcp.@host[6].mac='
dhcp.@host[6].ip=
dhcp.@host[6].leasetime='infinite'
dhcp.@host[7]=host
dhcp.@host[7].name='smartthingshub'
dhcp.@host[7].dns='1'
dhcp.@host[7].mac='
dhcp.@host[7].ip='
dhcp.@host[7].leasetime='infinite'
dhcp.@host[8]=host
dhcp.@host[8].name='hpofficejet'
dhcp.@host[8].dns='1'
dhcp.@host[8].mac=
dhcp.@host[8].ip='
dhcp.@host[8].leasetime='infinite'
dhcp.@host[9]=host
dhcp.@host[9].name='officedesktop'
dhcp.@host[9].dns='1'
dhcp.@host[9].mac=''
dhcp.@host[9].ip='
dhcp.@host[9].leasetime='infinite'
dhcp.@host[10]=host
dhcp.@host[10].name='tplinkarcher'
dhcp.@host[10].dns='1'
dhcp.@host[10].mac='
dhcp.@host[10].ip='
dhcp.@host[10].leasetime='infinite'
dhcp.guest=dhcp
dhcp.guest.interface='guest'
dhcp.guest.start='100'
dhcp.guest.limit='150'
dhcp.guest.leasetime='12h'
dhcp.@host[11]=host
dhcp.@host[11].name='oneplus-8t'
dhcp.@host[11].dns='1'
dhcp.@host[11].mac='
dhcp.@host[11].ip=
dhcp.@host[11].leasetime='infinite'

When I have reflashed I have just reflashed the same build - but on first boot it gives out dhcp addresses, but will restore from the saved config correctly, but then again dies when I reboot it....

your using doh or whatever it's called? someone else will probably come along and help you out... i'm not that knowledgeable on that side of things...

I should point out that I had gotten stubby working to do DNS over TLS (thus the dns forward), and wanted to give out alternate dns to a bunch hosts (which is why I have lan.dhcp.option set).

I can simplify it up again and go back to basics, but I wouldn't think options would cause total failure....

1 Like

The issue isn't with the dns side, it with the giving out of leases. I can certain delete that stuff and retry....

1 Like

fair point...

your starting at 200 and limiting 150... thats up to 350... which for most all /24 is invalid...

Well, interestingly in the spirit of simplifying, I went back removed the "dhcp.@dnsmasq[0].server='127.0.0.1#5453'", and removed the dhcp.@dnsmasq[0].noresolv='1' and suddenly it's giving out addresses again.

dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].localservice='1'
dhcp.@dnsmasq[0].ednspacket_max='1232'
dhcp.@dnsmasq[0].dnsforwardmax='1500'
dhcp.@dnsmasq[0].cachesize='5000'
dhcp.@dnsmasq[0].confdir='/tmp/dnsmasq.d'
dhcp.@dnsmasq[0].dnssec='1'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.limit='150'
dhcp.lan.leasetime='12h'
dhcp.lan.dhcpv4='server'
dhcp.lan.ra_slaac='1'
dhcp.lan.ra_flags='managed-config' 'other-config'
dhcp.lan.start='200'
dhcp.lan.dhcp_option='6, 208.67.222.222, 208.67.220.220'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'
dhcp.odhcpd=odhcpd
dhcp.odhcpd.maindhcp='0'
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.leasetrigger='/usr/sbin/odhcpd-update'
dhcp.odhcpd.loglevel='4'

So, presumably something I was doing on the DNS side was causing a silent fail on the DHCP side...

I am super confused, but happy I got it working. Thanks for your prompt response. Perhaps I need to do some more reading about dnsmasq....

I have this build

rpi4.64-snapshot-25777-2.9.17-2-r16357-ext4-sys.img.gz

and with torrents running, website are very slow to load. For example on YouTube video is streaming fine 1080p but images are not loading for videos(thumbnails)
Is it something to do with SQM?

not really... newer rpi4.qos if you are running it, is much better... but it won't magically stop / make torrents wait for other traffic... i'd need to see the output from the debugging commands as discussed, via PM, previously to confirm that some torrent traffic is not slipping through unclassified...

so you don't notice any issues with gaming or voip?

would definitely be best to pull down the latest qos... first before doing too much tho'... ( debugging commands etc.. as I need to fix the current script not old ones... if indeed it is the issue )

( most torrent apps allow setting of bandwidth limits... this should be your first point of call with such issues... if you have no control over those hosts... then you can set some firewall rules based on a range of ip-addresses to 'choke' greedy clients )

you can also invert RPI4QOS_GAMING_MACS by putting greedy macs in there... then setting a low DSCP value;

CS_GAMING="CS1"

if their macs don't hop around... that would ensure that clients traffic (4/6) is has a low priority... if this makes no difference... then the qos script is marking correctly to begin with...

Well, actually that didin't fix it, when I rebooted it again, again issues with no dhcp leases being handed out.

What appears to have finally fixed it was setting "dhcp.lan.force='1'", which according to what I know is supposed to forces DHCP serving on the specified interface even if another DHCP server is detected on the same network segment. I don't have any other dhcp servers, so not sure why this was necessary.

In any case, I have now rebooted multiple times and dhcp seems to be working correctly.

Just in case anyone else has this issue....

@anon50098793 is your rpi4qos available for non community builds, or is complicated to set up?

yes.. it is available as a .qos file at the github repo...

not really... a few prerequisites... which are internally checked for and one could argue that some features are r/w disk sensitive... ( dont enable persistent ipsets on rom based systems )... if you have basic ssh knowledge and can read documentation then you should be fine...