Wulfy23: is there a cron job for automatic rebooting or software updating preconfigured?
Because I am experiencing Internet breakup at around 6am or few minutes before that. After may be some 5 minutes that Internet is there again!!!
Is it only with me or known bug?
I am on latest stable release from you ( not snapshot).
ok... so your asking about any recurring automated stuff in the build...
(note: most things that happen in the build log something... so the quick answer to your question is just to check logread and dmesg from after this occurence once or twice)
it's a good question actually...
of course these things might vary depending on what INI options are enabled and whatnot... but it's good to give a brief overview of them anyway...
there is a cronjob that saves the above data every... need to check... probably 3-5hours... initially it worked really well without cronjob (had a shutdown hook) but if power suddenly is lost it didn't capture stuff so a cronjob was implemented...
there is a cronjob that saves the logread ringbuffer...
there are two cronjobs, backup/tasks which don't really do anything... (but the latest build has an updated tasks that works)
well, well, well I though most of the jobs would be around midnight-3:30am but looking at my crontabs... the 'not working' backup/tasks are right on 5:59am (mondays only maybe)...
In case this is helpful my LTE modem drops eth0 (NO-CARRIER using ip monitor) about every 48 hours as is apparent from checking the modem log and this needs to be detected and managed. Think this means udhcpc kill commands to release and renew.
On my RT3200 using the recent snapshots this is already correctly handled.
I wrote this script for Asus-Wrt Merlin:
ip monitor link dev eth0 | while read event; do
logger "maintain-wan-lease detected eth0 event: "$event
case $event in
if [ $renew_wan_lease -eq 0 ]; then
logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
killall -SIGUSR2 udhcpc
if [ $renew_wan_lease -eq 1 ]; then
logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
killall -SIGUSR1 udhcpc
This meant keeping my internet connectivity after the modem refreshes. Whereas otherwise internet connectivity would be lost until reboot.
May be worth just ruling this out.
Alternatively could this behaviour explain the constant refreshing IP?
be my guest (from a purely investigative perspective...) but keep in mind...
a) those jobs don't really do anything
b) you'll probably have to do it again after your next upgrade... I have some INI variables to turn that stuff off... but they need more testing... and as those jobs don't really do much... it hasn't been a priority as yet... (however in the new builds with the fixed tasks... there will be a NOTASKS or something like that which will work)
c) commenting out/removing any line with psave may interfere with luci-statistics / nlbwmon / logs if you lose power (someone who is uber paranoid about sdcard writes like if your router is in antarctica or something might benefit from those being switched off)
ACS support is... A complete and total disaster. It was implemented with https://github.com/openwrt/openwrt/commit/df773ead9a8e4ef492a35a0d936fefbe2066e729#diff-892e932d8d1c8b619fa9f0337a9c5e83e1e0e41dae8cb6125d660e283b1bf069 - and that patch has no header information indicating whether John wrote it himself, or pulled it from somewhere. It's completely different than Cypress' current ACS patch, and both patches in their current state cause major roaming issues for clients too. (They report a noise value of 0 during a client scan for anything but the current connected AP, which results in a negative SNR, so it'll stick forever on the first AP it associates with. Not a problem for home users with a single router and different SSIDs for each band, but bad if you're putting your device on a vehicle moving 6 MPH in a warehouse with dual-band enterprise WLAN.)
I'd just back out the patch locally since I don't use AP mode, except knowing that 2.4GHz noise floor is insanely high is also kinda necessary.
Every firmware revision I've tried (Raspi upstream blobs from RPi-distro, cypress-firmware ancient blobs, linux-firmware cypress/ blobs) behaves similarly. I have a patch that makes things suck slightly less, but it's a fugly hack and things still behave poorly in many cases.
meh... 3.5.139-21-r18086 is not super outstanding in the larger scheme of things...
there are quite a few ssl bugfixes... and one should always assess security risk on their own... but;
if you are not using browsers on your router etc
you don't have a nested lan or ottherwise more exposure to dns/mitm
you don't really need something from the newer builds
then i'd asses the risks as medium at best... and if I were you... i'd be fairly comfortable holding off for another month or so OR update to 21.02.1 which is a tad more reliable and still has most fixes... ( better yet wait for 21.02.2 )...
Luckily my actual threat surface is pretty narrow...
Is the 21.02.1 a version of your build, or are you refering to the the official openwrt build for rpi4? After spending a bunch of time installing and playing with your build (which as been great) last winter, I realize I am now acting like someone who should stick with a just works official build and upgrade infrequently...
If I decide to just move to the official openwrt build will most of my config come across OK?
unless I say 'official' i'm referring to my variant but purely for ease of migration... and either will work
if you use the backup from the updatecheck bar... then install official from factory... then restore settings... yes should mostly be ok...
i dunno... as i've got 'release' variants... you can just stick to those... and some of the builds migration tweaks may actually make things easier for you...
if you don't have masses of data parked somewhere unknown... (same for fancy service config files etc.)... then upgrade is usually very smooth... and myself and several other users here upgrade alot... with little to no issues...
besides... there is only one way to find out! ( official or not )...