i think based on what we've tried, we are left with something related to
power, hardware
or
additional software
as there was intermittency involved, i'm leaning towards the hardware but it's almost 50/50...
at this point, the only real option is to try 'normal OpenWrt'... given an identical software stack, my gut feelings are that the issue will persist...
autorate note
(i think you've been using or previously used the newer non-build included autorate service... it is better than the build included one which was pretty hacky and quickly whipped up as a test - actually i dont think anyone is using it and its abit old so I will probably remove it...)
there is busybox reboot -f (we didn't try -f)... that still doesn't work we are more on the hardware side... if it works... you can disable services one by one... until you find what's causing it...
( pswww output requested earlier was not provided - which is fine, but leaves huntng down issues in that domain entirely up to you )
wildcard theory
gotta admit, compromise has crossed my mind once or twice as well (hence the busybox shasum we did), devices not rebooting or sporadically rebooting... and you've looked at the obvious things (which is difficult especially on a hardware level on these boards)... it's probably alarmist... but definitely something worth mentioning given the symptoms...
yeah... that's a good point... and it's well worth examining them for anything obvious...
the way those work is;
a dmesg is saved early on boot pdmesg*
a logread is saved periodically (appended) plogread*
so, if you quickly reboot, you'd possibly be missing all the logread stuff which will show you the later service related stuff..
and you'd need to leave the thing running for hmmmm... not sure if I do a logread save at the end of boot or every 6 hours or something... (edit: I think a 'clean' shutdown/reboot will also do a save)
point is... you may not have the service stuff there...
but worth scanning them for the times when you thought the device didn't boot to see if anything obvious shows up...
NOTE:
we used to keep these semi indefinately... ( 3months plus )
they were starting to impact upgrade speed for long running build users, now they are trashed over a certain size ( probably around 11 upgrades worth but its sized based so I suppose if you never reboot and you have alot of logspam it can theoretically trash/move them all)
there are two ways you can 'keep' older ones without slowing down upgrade...
ROOTFSEXPAND_DATAPART automatically 'syncs' /boot/plog to your z drive...
when files are trashed... they can optionally be moved
(second parameter is optional but defaults to the above subfolder afaik)
there is also a command logreadp that is for dumping/searching the whole persistent log/logs but it's WIP / experimental...
[root@dca632 ../_WANSWITCHER 52°] logreadp --help
logreadp #dump full current persistentlog
logreadp -a #dump all saved
logreadp -F "<string>" #fgrep all saved aka show release and date of logfiles
logreadp info
[root@dca632 ../_WANSWITCHER 52°] logreadp info
dir: /boot/plog fnum:40 tlines:58312
current: /boot/plog/plogread-202202281432-boot-5.0.103-30.log
oldest: /boot/plog/plogread-202202091324-boot-5.0.77-139.log
Hi Wulfy: how do i update the eeprom of Rpi4 while using your latest build ?
i flashed your latest firmware and the very first popup was this one to update eeprom, but i didnt find a way on how to do it...
I am having another problem since I update from 5.0.11-73 to 5.0.103-12 from web interface.
WireGuard interface goes down and never recover after few hours connected, if I am using a device with vpn it stays active, in the night that all devices are in standby the WireGuard interface crashes. A reboot bring everything to normal , and yes I’m using persistent keepalive = 25.
With old firmware I was with an uptime from almost 30 days without any problem.
fyi anyone using the wireless... + used a factory image over the last two months maybe...
we/you could be effected by this;
in other words you may have both hwmode AND band options in your /etc/config/wireless, have not tested how that works but afaik it doesn't...
remove 'hwmode' if you have both...
the 'generator' script has been fixed... but I guess it could use one more tweak to set that only if it's defined in INI, as afaik, the default is 5g/11a anyway...
You are right. After 24h the WireGuard said as connected in the openwrt interface but without connection and with handshake : never in WireGuard settings from openwrt.
I added persistentkeepalive on peer from server side, it was only on client side.
It is strange why it happened only right now, maybe some update from raspberry pi server using pivpn. It has unattended system upgrades for security reasons, so maybe updated and caused that.
