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.
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...
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....
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....
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.
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.
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...
@anon50098793 I have a question: how do you stand about the use of f2fs. In matter of performance it shouldnt really matter with a recent kernel, but it can still quite extend the lifetime of an sdcard.
in a general sense... for casual / new use... then f2fs or similar is either preferable... or more consistent with common openwrt principles... only when you start to build your own images / add huge amount of add-on apps / implement custom backup stuff does the choice become particularly relevant...
with this build... and my personal preference for any removable disk... is that unless the device is in an un-serviceable location... ( i.e. another state ) then I much prefer to use ext2/3/4 or 'full r/w' style installs... primarily because...
storage is accessible / replacable
modern good disks are decently reliable ( and cheap )
resizing, manual backing up of, custom mods for... these style of disks are far more common / direct...
performance specs are arguable... but in my experience... when we are talking about sd/emmc/ssd then there is little or no performance factor that comes into play...
Well i used f2fs a lot on rpis since 2015 and never had an hiccup, so i guess im biased and would really love to see a build with it
Just for me the additional power need for an hdd/ssd isnt worth it if i can get a similar lifespan in just using another filesystem. Of course neither will ever replace backups.
For you, its probably not worth the additional work of managing another image.
( and at the start of this build these were 'almost' supported )
but I'm probably way too far down the track now ( too much stuff is gonna break.. on this build ) to attempt converting all the custom stuff to squashfs etc. support
if you want to test/use... by all means let me know and i'll upload one... but it means you'll lose all the upgradability ( you'll have to flash factories all the time ) ( and likely manually scp config files for settings restore )
i gotta admit my knowledge is pretty weak in this regard...
although, at one stage i'd almost finished a multiboot->initramfs option that loaded it's config from /boot which would likely achieve similar outcomes?
