Curious to know if on reboots or renewals anyone here also gets new IP's instead of re-using the same one from DHCP? I really want to figure out how to get openwrt re-use the IP..
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: received SIGTERM
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: unicasting a release of X.X.X.X to X.X.X.X
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: sending release
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: entering released state
Mon Dec 6 21:58:37 2021 user.notice dhcp.script: deconfig IFACE6RD_DELEGATE=0 SHLVL=1 J_V_keep=0 HOME=/ T_J_V_interface=string interface=eth0 T_J_V_link_up=boolean T_J_V_action=int TERM=linux PATH=/usr/sbin:/usr/bin:/sbin:/bin J_V_interface=wan K_J_V= action link_up keep interface J_V_link_up=0 J_V_action=0 N_J_V_link_up=link-up INTERFACE=wan T_J_V_keep=boolean PWD=/lib/netifd/proto JSON_CUR=J_V
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: started, v1.33.1
Mon Dec 6 21:58:37 2021 user.notice dhcp.script: deconfig IFACE6RD_DELEGATE=0 SHLVL=1 J_V_keep=0 HOME=/ T_J_V_interface=string interface=eth0 T_J_V_link_up=boolean T_J_V_action=int TERM=linux PATH=/usr/sbin:/usr/bin:/sbin:/bin J_V_interface=wan K_J_V= action link_up keep interface J_V_link_up=0 J_V_action=0 N_J_V_link_up=link-up INTERFACE=wan T_J_V_keep=boolean PWD=/lib/netifd/proto JSON_CUR=J_V
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: sending discover
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: sending select for X.X.X.X
Mon Dec 6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: lease of X.X.X.X obtained, lease time 86400
the other option available / next fastest way to rule out anything build related is to install official OpenWrt on a spare sdcard (configure from scratch)
I have a whole bunch of fancy ipv6 modules and not so much experience with what they do... so the above will rule out any adverse interactions here...
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...
persistent nlbwmon/luci-statistics
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...
persistent logs
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)...
there are a few other jobs that may be automated (i.e. wireguard watchdog) but they not commonly enabled or used so i'd have to lookup / check any logic if anyone finds additional jobs present...
the other jobs appear to run 4 times a day...
for now just comment out those lines maybe and restart cron service... (that said, those jobs as mentioned don't really do much so a little lost on whats going on)
best guess would be an ISP/UPSTREAM reset kindof thing (i see similar behavior sometimes on my cable connection around 3am where it stops working for maybe less than a minute)...
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:
#!/bin/bash
renew_wan_lease=0
ip monitor link dev eth0 | while read event; do
logger "maintain-wan-lease detected eth0 event: "$event
case $event in
*'NO-CARRIER'* )
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
renew_wan_lease=1
fi
;;
*'LOWER_UP'* )
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
renew_wan_lease=0
fi
;;
esac
done
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?
So that means, you have configured some cron jobs which run at 05:59am on some days a week.
Can I change it? Or will it cause problems with other settings?
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.
Hi. Any idea why clicking "save" on SQM gives me this error?
An error occurred while saving the form:
Option "Queuing disciplines useable on this system. After installing a new qdisc, you need to restart the router to see updates!" contains an invalid input value.
It works properly. Just choose the settings inside after reading each config and choose the one which suits your needs. Then you will see the difference.
Folks. I am "way behind" on updating - still running OpenWrt SNAPSHOT r16595-f4473baf6e.
I'd be interested in updating but don't want to totally hose my system (which has been very stable).
Any major breaking bugs I should be aware of? Can I just upload and flash the most recent stable version, which appears to be rpi4.64-snapshot-27006-3.5.139-21-r18086-ext4-sys.img?
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 )...
