What's new

[WICENS] WAN IP Change Email Notification Script

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Version 4 is ready with reboot notifications

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 🙏
 
Version 4.00 is now available

Code:
## 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
 
Version 4.00 is now available

Code:
## 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
Awesome thank you :)

1. Should I now remove this from service-start?
Code:
nohup sh /jffs/scripts/reboot-notify.sh >/dev/null 2>&1 & # added by KM from Maverickcdn (wicens)
2. Should I now delete the reboot-notify.sh script from your interim post above?

Thanks!
 
1. Should I now remove this from service-start? YES
2. Should I now delete the reboot-notify.sh script from your interim post above? YES
The wicens version is more robust and includes recorded uptime prior to reboot in the Email message
 
The wicens version is more robust and includes recorded uptime prior to reboot in the Email message
Hi, amtm recently showed this (see pics) which after I tried to update the script, still comes up when I press ‘u’ for update in amtm.

It’s just a checksum apparently, so it goes away eventually, just a FYI at this point?
 

Attachments

  • IMG_1221.jpeg
    IMG_1221.jpeg
    54.3 KB · Views: 22
  • IMG_1220.jpeg
    IMG_1220.jpeg
    62.6 KB · Views: 22
It’s just a checksum apparently, so it goes away eventually, just a FYI at this point?
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
 
Last edited:
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
🤔
1000048809.jpg
 
Also, the color option now doesn't work on V4.
It keeps showing b&w
 
Yes this was the issue that was just corrected, the script was finding more than one instance of 'script_version=' and borking the output

Also, the color option now doesn't work on V4.
It keeps showing b&w
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
Thanks!

Regarding the color, it was nothing there. Was blank.
I changed it to 1 and problem solved!

Regarding the update, I had to manually download the script again, the update wasn't working properly. Second problem solved! ☺️
 
Regarding the update, I had to manually download the script again, the update wasn't working properly. Second problem solved! ☺️
Thanks, fixed my MD5 flag too. 👍🏼
 
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).
Could it be one email for the router reboot notification and another for the IP change ?
 
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).
Couple things... at the bottom of the Email is the time and call option (cron/wancall/etc)

Are both Emails identical for the IP change... times & call type? My guess right now is 1 will be wancall and the other will be cron.

If you're willing can you PM me or post your logs from startup after reboot until the success message of the last email sent
 
Couple things... at the bottom of the Email is the time and call option (cron/wancall/etc)

Are both Emails identical for the IP change... times & call type? My guess right now is 1 will be wancall and the other will be cron.

If you're willing can you PM me or post your logs from startup after reboot until the success message of the last email sent
I just checked and it's exactly what you said - one wancall and the other one the Cron...
Do you still need the logs?
 
I just checked and it's exactly what you said - one wancall and the other one the Cron...
Do you still need the logs?
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
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top