Just need to find time to merge it to github, I'll think about adding wan down/up notifications but I don't have much free time these days. The script was re-written from the ground up and is now more modular and shouldn't be that difficult just need time
That’d be awesome appreciate you taking the time. No hurry from my side.
Just a thought for the WAN down / up notification if you could add a switch with a parameter to only send an email if it goes down X times within a period Y, or something similar. Thanks
## 4.00
* NEW: Router Reboot notification
* NEW: html formatting
* FIXED: various bug fixes
* REMOVED: multiple Emails/intervals were removed, script now functions for 1 Email per notification type only
* CHANGED: script performance and efficency increased, focused on modularity
* CHANGED: amtm config now syncs instead of overwriting wicens config, only 1 config can be used at once
* CHANGED: notification types (wanip/reboot/fwupdate/script-update) can be independently enabled/disabled
* ADDED: cgnat WAN IP warning
* ADDED: wicens_update_config.wic now contains a few adjustable timeouts/freq etc.
* NOTE: wan ip change history files from v3 will be misaligned in v4 emails
## 4.00
* NEW: Router Reboot notification
* NEW: html formatting
* FIXED: various bug fixes
* REMOVED: multiple Emails/intervals were removed, script now functions for 1 Email per notification type only
* CHANGED: script performance and efficency increased, focused on modularity
* CHANGED: amtm config now syncs instead of overwriting wicens config, only 1 config can be used at once
* CHANGED: notification types (wanip/reboot/fwupdate/script-update) can be independently enabled/disabled
* ADDED: cgnat WAN IP warning
* ADDED: wicens_update_config.wic now contains a few adjustable timeouts/freq etc.
* NOTE: wan ip change history files from v3 will be misaligned in v4 emails
You're too quick. I literally just pushed a couple minor updates (no version change) to the script update function, 1 was cosmetic, the other fixed issues with pulling the newer version numbers if there ever is another update (as seen in your second photo)
The MD5 update is amtm seeing the script has changed but without a version update
You're too quick. I literally just pushed a couple minor updates (no version change) to the script update function, 1 was cosmetic, the other fixed issues with pulling the newer version numbers if there ever is another update (as seen in your second photo)
The MD5 update is amtm seeing the script has changed but without a version update
I changed the color option flag from 'yes' to '1', this should have been automatically handled after first run of 3.41 -> 4.00 (it worked in my testing) If anything try restarting the script and toggling it off then back on. If that doesn't work check what opt_color= is set to in /jffs/addons/wicens/wicens_user_config.wic
Code:
# v3->v4 adjustments ################### set new vars/format v3 vars/set new v4 vars w/loaded v3 config
if [ "$(F_printfstr "$build_settings_version" | cut -d'.' -f1)" -le 3 ] ; then
# added vars
user_wanip_notification=1 # we assume if v3, wanip was enabled
user_reboot_notification=0
user_email_from='wicens script'
# states are inverted
if [ "$amtm_import" = 0 ] ; then amtm_import=1 ; else amtm_import=0 ; fi
if [ "$user_update_notification" = 0 ] ; then user_update_notification=1 ; else user_update_notification=0 ; fi
if [ "$user_fw_update_notification" = 0 ] ; then user_fw_update_notification=1 ; else user_fw_update_notification=0 ; fi
if [ "$log_cron_msg" = 0 ] ; then log_cron_msg=1 ; else log_cron_msg=0 ; fi
# var names were changed
user_login_addr="$user_from_addr"
user_from_addr="$user_from_name"
# set to never if empty
[ -z "$last_cron_run" ] && last_cron_run='never'
[ -z "$last_wancall_run" ] && last_wancall_run='never'
[ -z "$last_ip_change" ] && last_ip_change='never'
[ -z "$update_date" ] && update_date='never'
# change to new date format
for var_update in last_cron_run last_wancall_run last_ip_change install_date update_date saved_wan_date created_date
do
new_value="$(eval "F_printfstr \"\${$var_update}\"" )"
if [ -n "$new_value" ] && [ "$new_value" != 'never' ] ; then
new_value="$(F_printfstr "$new_value" | sed 's/^... //;s/@ //g')"
eval "$var_update=\"\$new_value\""
else
F_replace_var "$var_update" 'never' "$config_src" # if blank in v3 force to never
fi
done
if [ -f "$history_src" ] ; then
sed -i 's/^... //;s/@ //g' "$history_src"
fi
# new color set vars
case "$opt_color" in
'yes') opt_color=1 ;;
'no') opt_color=0 ;;
esac
[ -f '/tmp/wicens.lock' ] && rm -f /tmp/wicens.lock # remove old v3 lock
fi
# end of v3->v4
Yes this was the issue that was just corrected, the script was finding more than one instance of 'script_version=' and borking the output
I changed the color option flag from 'yes' to '1', this should have been automatically handled after first run of 3.41 -> 4.00 (it worked in my testing) If anything try restarting the script and toggling it off then back on. If that doesn't work check what opt_color= is set to in /jffs/addons/wicens/wicens_user_config.wic
Code:
# v3->v4 adjustments ################### set new vars/format v3 vars/set new v4 vars w/loaded v3 config
if [ "$(F_printfstr "$build_settings_version" | cut -d'.' -f1)" -le 3 ] ; then
# added vars
user_wanip_notification=1 # we assume if v3, wanip was enabled
user_reboot_notification=0
user_email_from='wicens script'
# states are inverted
if [ "$amtm_import" = 0 ] ; then amtm_import=1 ; else amtm_import=0 ; fi
if [ "$user_update_notification" = 0 ] ; then user_update_notification=1 ; else user_update_notification=0 ; fi
if [ "$user_fw_update_notification" = 0 ] ; then user_fw_update_notification=1 ; else user_fw_update_notification=0 ; fi
if [ "$log_cron_msg" = 0 ] ; then log_cron_msg=1 ; else log_cron_msg=0 ; fi
# var names were changed
user_login_addr="$user_from_addr"
user_from_addr="$user_from_name"
# set to never if empty
[ -z "$last_cron_run" ] && last_cron_run='never'
[ -z "$last_wancall_run" ] && last_wancall_run='never'
[ -z "$last_ip_change" ] && last_ip_change='never'
[ -z "$update_date" ] && update_date='never'
# change to new date format
for var_update in last_cron_run last_wancall_run last_ip_change install_date update_date saved_wan_date created_date
do
new_value="$(eval "F_printfstr \"\${$var_update}\"" )"
if [ -n "$new_value" ] && [ "$new_value" != 'never' ] ; then
new_value="$(F_printfstr "$new_value" | sed 's/^... //;s/@ //g')"
eval "$var_update=\"\$new_value\""
else
F_replace_var "$var_update" 'never' "$config_src" # if blank in v3 force to never
fi
done
if [ -f "$history_src" ] ; then
sed -i 's/^... //;s/@ //g' "$history_src"
fi
# new color set vars
case "$opt_color" in
'yes') opt_color=1 ;;
'no') opt_color=0 ;;
esac
[ -f '/tmp/wicens.lock' ] && rm -f /tmp/wicens.lock # remove old v3 lock
fi
# end of v3->v4
When I manually reboot the router, my IP changes.
Then, I receive an email saying the router was rebooted (correct) and two emails with the IP change (duplicate emails).
When I manually reboot the router, my IP changes.
Then, I receive an email saying the router was rebooted (correct) and two emails with the IP change (duplicate emails).
When I manually reboot the router, my IP changes.
Then, I receive an email saying the router was rebooted (correct) and two emails with the IP change (duplicate emails).
Okay thanks, I can do without the logs. If you could just confirm there should be a wancall entry saying its sleeping 40s secs and then another wancall entry saying the IP has changed and sending a notification... in-between that should be a cron entry also seeing the IP has changed.
This is an issue with cron running before wancall has completed and updated the IP. I had a feeling changing my script lock structure would introduce something like this, I still can't wrap my head around a locking mechanism that prevents this but still allows the script to run more than once at the same time for other call types (reboot/fwupdate). I guess if anything it worked as intended. I will chew on this and will come up with something in the next week or two hopefully
Turns out I already had the control in place for this... any chance I can still get your logs?
Code:
# if script is running with call type other than cron don't run cron
elif [ -f '/tmp/wicens_lock.fwupdate' ] || [ -f '/tmp/wicens_lock.wancall' ] || [ -f '/tmp/wicens_lock.reboot' ] || [ -f '/tmp/wicens_lock.send' ] ; then
if [ "$run_option" = 'cron' ] ; then
exit 0
fi
fi
Turns out I already had the control in place for this... any chance I can still get your logs?
Code:
# if script is running with call type other than cron don't run cron
elif [ -f '/tmp/wicens_lock.fwupdate' ] || [ -f '/tmp/wicens_lock.wancall' ] || [ -f '/tmp/wicens_lock.reboot' ] || [ -f '/tmp/wicens_lock.send' ] ; then
if [ "$run_option" = 'cron' ] ; then
exit 0
fi
fi
I'm sorry I'm late, but i read that you didn't need the logs and I didn't read the whole post
Here are the logs imediatly after a reboot (i stripped all the lines not related to wicens):
Code:
May 20 21:38:20 GT-AX6000 wicens[3729]: wancall : Started by 'wan-event connected' trigger, sleeping 40 seconds before running IP compare
May 20 21:38:21 GT-AX6000 wicens[6289]: reboot : Started by services-start, reboot detected, sending reboot notification in 20 seconds
May 20 21:38:41 GT-AX6000 wicens[6289]: reboot : Sending router reboot notification
May 20 21:38:44 GT-AX6000 wicens[6289]: reboot : Finished sending router reboot Email notification
May 20 21:38:46 GT-AX6000 wicens[11027]: cron : Success sending Email notification, update devices to MY_IP
May 20 21:38:46 GT-AX6000 wicens[11027]: cron : Updated script with WAN IP MY_IP
May 20 21:39:00 GT-AX6000 wicens[3729]: wancall : WAN IP has changed to MY_IP
May 20 21:39:00 GT-AX6000 wicens[3729]: wancall : Attempting to send WAN IP change Email notification to MY@EMAIL
May 20 21:39:03 GT-AX6000 wicens[3729]: wancall : Success sending Email notification, update devices to MY_IP
May 20 21:39:03 GT-AX6000 wicens[3729]: wancall : Updated script with WAN IP MY_IP
All good, thanks for the reply. Strangely you're missing some logging I would expect but its possible it ran prior to syslogd being started, or maybe you're using something like scribe and was in-between? without the full log I couldn't say for certain
You're missing wicens[11027]: cron : WAN IP has changed to... and wicens[11027]: cron : Attempting to send...
Im not sure what to make of this.. some of the timing looks weird and wancall shouldn't have seen a different IP running 14 secs after cron did
Is this router in Dual NAT (wan ip is private?)
If you want you can add F_uptime && [ "$router_uptime" -lt 300 ] && exit 0 to line 4161 prior to the NTP check for cron, this will prevent cron from running if the router hasn't been up for 5 mins