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!

New issue rn is--my IP actually changed, but the old IP isn't actually replaced by the new one after the notification. I got a new 'new IP' notification every 10 minutes for 40 minutes, not sure if this is a permissions issue or something. This was on v3.20 though (I forgot to check for the update), so maybe the 'Sunday logging' issue had something to do with it? (Sunday the 9th was the last time I got a new IP.)
ED: This is happening on 3.30, too, I just got another notification lol.

Also, I switched to a diff (earlier) version asuswrt-merlin while troubleshooting issues (which is what caused me to get a new IP in the first place, I suppose), but this doesn't seem to be reflected in the banner, it still has the newer 386.10 written there.
Otherwise, and this stuff is minor but: while downloading and upgrading to new script, I'm pretty sure the script download function said 'dowloading', not 'downloading'. May also want to change the menu text for 'Update check' to 'Install update' after a successful update check is executed, and/or give the user the option to install the update as a yes/no option after an update is successfully detected by the update check. I would poke around and try to make these small modifications myself but won't have the time for a bit :/
 
So it looks like there are multiple instances fighting each other? Because of the cron config? Like they were meant to be killed, but weren't in the right order, so each time, you end up with one more process than you need (which is also? why cron thinks it has two emails to send? There are a bunch of references to 'email 1 of 2'.) I'm not sure why none of the processes update the value of the current IP immediately after firing off the email though.

Code:
Apr 14 07:30:01 wicens[6442]: cron: NOTICE - Removed stale wicenssendmail.lock file started by Option : cron  on Created Fri Apr 14 2023 @ 07:20:00

Apr 14 07:30:01 wicens[6442]: cron: Lock file exists for running process older than 5 mins but not sending Email

Apr 14 07:30:01 wicens[6442]: cron: Killing old process 25735 started by Option : cron  and deleting lock file Created Fri Apr 14 2023 @ 07:20:00

Apr 14 07:30:01 wicens[6442]: cron: Done, killed stale process, removed lock file

Apr 14 07:30:04 wicens[6442]: cron: WAN IP has changed to this.is.the.new-ip

Apr 14 07:30:10 wicens[6442]: cron: Done sending Email 1 of 2 update your clients to this.is.the.new-ip

Apr 14 07:30:10 wicens[6442]: cron: Sleeping 3h before sending next Email

Apr 14 07:40:00 wicens[20132]: cron: NOTICE - Removed stale wicenssendmail.lock file started by Option : cron  on Created Fri Apr 14 2023 @ 07:30:00

Apr 14 07:40:00 wicens[20132]: cron: Lock file exists for running process older than 5 mins but not sending Email

Apr 14 07:40:00 wicens[20132]: cron: Killing old process 6442 started by Option : cron  and deleting lock file Created Fri Apr 14 2023 @ 07:30:00

Apr 14 07:40:00 wicens[20132]: cron: Done, killed stale process, removed lock file

Apr 14 07:40:03 wicens[20132]: cron: WAN IP has changed to this.is.the.new-ip

Apr 14 07:50:02 wicens[32617]: cron: WAN IP has changed to this.is.the.new-ip

Apr 14 07:52:04 rc_service: dhcp6c 9552:notify_rc restart_ddns

Apr 14 07:52:04 custom_script: Running /jffs/scripts/service-event (args: restart ddns)

Apr 14 07:52:04 ddns: update PROVIDER, wan_unit 0

Apr 14 07:52:04 ddns: Clear ddns cache.

Apr 14 07:52:04 custom_config: Appending content of /jffs/configs/inadyn.conf.add.

Apr 14 07:52:04 ddns: Start Inadyn(10).

Apr 14 07:52:05 inadyn[9663]: In-a-dyn version 2.10.0 -- Dynamic DNS update client.

Apr 14 07:52:05 inadyn[9663]: Guessing DDNS plugin PROVIDER

Apr 14 07:52:05 inadyn[9663]: Update forced for alias ALIAS1, new IP# this.is.the.new-ip

Apr 14 07:52:05 inadyn[9663]: Update forced for alias ALIAS2, new IP# this.is.the.new-ip

Apr 14 07:52:08 inadyn[9663]: Updating cache for ALIAS1

Apr 14 07:52:09 inadyn[9663]: Updating cache for ALIAS2

Apr 14 08:00:03 wicens[12122]: cron: WAN IP has changed to this.is.the.new-ip

Apr 14 08:10:02 wicens[25541]: cron: WAN IP has changed to this.is.the.new-ip

Apr 14 08:20:00 wicens[29393]: cron: Lock file exists for running process older than 5 mins but not sending Email

Apr 14 08:20:00 wicens[29393]: cron: Killing old process 26927 started by Option : manual  and deleting lock file Created Fri Apr 14 2023 @ 08:10:28

Apr 14 08:20:00 wicens[29393]: cron: Done, killed stale process, removed lock file

Apr 14 08:20:02 wicens[29393]: cron: WAN IP has changed to this.is.the.new-ip

Apr 14 08:20:07 wicens[29393]: cron: Done sending Email 1 of 2 update your clients to this.is.the.new-ip

Apr 14 08:20:08 wicens[29393]: cron: Sleeping 3h before sending next Email

It may be that wicens itself doesn't understand that it was in fact successful at sending the email to begin with? Which is why it sticks around for 600 seconds, at which point cron thinks, 'welp, let's try again'?
 
It sure looks like it thinks it was unsuccesful, but I'm not sure why. The email log is successful, and yet there are all these successive attempts. Hopefully it'll stop after four.

#!/bin/sh
wicens_wanip_retry_time=1681474800
# Attempting to send wan ip change notification Fri Apr 14 2023 @ 08:20:02
# Attempting to send wan ip change notification Fri Apr 14 2023 @ 08:30:03
# Attempting to send wan ip change notification Fri Apr 14 2023 @ 08:40:03
# Attempting to send wan ip change notification Fri Apr 14 2023 @ 08:50:02

Double-checking the settings, it doesn't seem that 'Current saved WAN IP' ever changes. I guess that's only done at the end of a successful notification run, but I'm not sure why the script thinks it was unsuccessful.
 
The interval between notifications, I guess, I set to 3 hours. So the script, I guess, runs for that long. However cron thinks that if a script runs for longer than 600 seconds, it is time to kill it and try again. I will test this by lowering the interval down to 3 minutes and forcing a DDNS update (which apparently is an event that causes wicens to fire--that's why I left that part of the log in a few posts previous).
 
Last edited:
Yup, that worked. It looks like unless the cron timeout interval of ASUSwrt(-merlin) is something configurable, the maximum interval between the two emails needs to be less than 600 seconds (maybe with like a 30 second buffer to allow for the time it takes to send the emails themselves, so 570, or 9.5 minutes) or, if the user specifies a second email be sent later than that, that second email should be executed via another cron job generated by wicens itself, which is then removed from cron on its successful completion (provided this is possible).
Frankly, I don't need more than one message telling me that the IP has changed, so perhaps we could make the second notification optional altogether?
 
New issue rn is--my IP actually changed, but the old IP isn't actually replaced by the new one after the notification. I got a new 'new IP' notification every 10 minutes for 40 minutes, not sure if this is a permissions issue or something.
Something is wrong with my lock check, this will take me some time to investigate
the script download function said 'dowloading', not 'downloading'. May also want to change the menu text for 'Update check' to 'Install update' after a successful update check is executed, and/or give the user the option to install the update as a yes/no option after an update is successfully detected by the update check.
I will correct the spelling and will clarify between update check and install with y/n
Double-checking the settings, it doesn't seem that 'Current saved WAN IP' ever changes. I guess that's only done at the end of a successful notification run, but I'm not sure why the script thinks it was unsuccessful.
Script doesnt update until all notifications sent, but the issue with the lock check it thinks it failed to send and is attempting re-sending hence the notification every 10 mins with cron

Please for now just set to one notification and it should not have any issues
 
v3 I moved around sourcing the user settings which is now happening after the lock check although the lock check requires the user variables when having multiple notifications configured... doh

Should be an easy fix, Ill try and get to it tonight
 
Last edited:
3.40
* FIXED: script lock broken when multiple notifications set
* FIXED: re-source configs after they are updated
* ADDED: remove retry file when forcing lock file removals
* ADDED: install update confirmation, reworded menu update/install
* CHANGED: lock optimization, better wording/debug info
* CHANGED: made awk random number generator faster for internet check

Fingers crossed last major fix for v3. Thanks to @LastSilmaril for the report
 
Fingers crossed last major fix for v3.

@Maverickcdn Congrats on v3.40!

Very, very minor thing I noticed. My wicens "header" now says Firmware Version 388.0 when I'm actually running 388.2 final release.

Code:
  Sun Apr 16 2023 @ 09:22:57 -- ver: 3.40 -- RT-AX86U FW ver: 388.0
 
Very, very minor thing I noticed. My wicens "header" now says Firmware Version 388.0 when I'm actually running 388.2 final release.
Oversight again by me 🥸

3.41
* ADDED: support for 388fw

Hope it works out
 
@Maverickcdn I finally updated from script version 1.0 today (hey, 1.0 was working as intended, so why take the chance). The latest version 3.41 works great, congratulations.

One request: the possibility of either pulling the "friendly name" from the amtm email or allowing editing of the "friendly name" (the from "display name") in your script. I have all my router notifications come from one particular "friendly name" so I can sort and delete, and it would be most helpful if wicens could display the same name.

(I have manually edited your script to send from my preferred display name, but then it triggers the hotfix notification. It currently defaults to 'wicens script'. Unless I'm missing how to change it as one of the settings.)

Cheers,
 
Last edited:
One request: the possibility of either pulling the "friendly name" from the amtm email or allowing editing of the "friendly name" (the from "display name") in your script.
3.20 the script changed the way the wicens 'from name' was handled. Its now in-line with proper Email header formatting like thelonelycoder and jackyaz scripts, and with amtm sync pulls from FROM_ADDRESS. It should match your USERNAME login email address unless your email provider allows aliasing the Email from address... ie login is 123@myemail.com recipient sees email from 456@myemail.com

Code:
 echo "Subject: Router testmail $(date +"%a %b %d %Y")" >/tmp/amtm-mail-body
        echo "From: \"amtm\" <$FROM_ADDRESS>" >>/tmp/amtm-mail-body
        echo "Date: $(date -R)" >>/tmp/amtm-mail-body
        echo "To: \"$TO_NAME\" <$TO_ADDRESS>" >>/tmp/amtm-mail-body
        echo >>/tmp/amtm-mail-body
        ...
        echo " Very truly yours," >>/tmp/amtm-mail-body
        echo " Your $FRIENDLY_ROUTER_NAME router (Model type $routerModel)" >>/tmp/amtm-mail-body
Code:
            echo "From: \"connmon\" <$FROM_ADDRESS>"
            echo "To: \"$TO_ADDRESS\" <$TO_ADDRESS>"
            echo "Subject: $EMAILSUBJECT"
            echo "Date: $(/bin/date -R)"
            echo "MIME-Version: 1.0"
            echo "Content-Type: multipart/mixed; boundary=\"MULTIPART-MIXED-BOUNDARY\""
            echo ""
Code:
[ -n "$user_send_to_cc" ] && echo "Cc: $user_send_to_cc"
        [ -z "$user_custom_subject" ] && echo "Subject: WAN IP has changed on $fw_device_model" || echo "Subject: $formatted_custom_subject"
        echo "From: \"wicens script\" <$user_from_name>"
        echo "Date: $(/bin/date -R)"
        echo "To: \"wicens user\" <$user_send_to_addr>"
        echo ""

Is it this line you need editable? to edit 'wicens script'?
Code:
echo "From: \"wicens script\" <$user_from_name>"

My understanding if you're syncing with amtm, the only place FRIENDLY_ROUTER_NAME is used is in the body of the message
 
3.20 the script changed the way the wicens 'from name' was handled. Its now in-line with proper Email header formatting like thelonelycoder and jackyaz scripts, and with amtm sync pulls from FROM_ADDRESS. It should match your USERNAME login email address unless your email provider allows aliasing the Email from address... ie login is 123@myemail.com recipient sees email from 456@myemail.com

<<snip>>

Is it this line you need editable? to edit 'wicens script'?
Code:
echo "From: \"wicens script\" <$user_from_name>"

My understanding if you're syncing with amtm, the only place FRIENDLY_ROUTER_NAME is used is in the body of the message
Yes, that verbiage appears 3 times in the script, I changed each instance (lines 1916, 2743 and 2855).

On my version of amtm, option 4. Edit Router name appears to be the "friendly name" (from name) on email messages, which is confirmed in the /jffs/addons/amtm/mail/email.conf file, which on line 5 shows FRIENDLY_ROUTER_NAME="RT-AX86U" (amtm version 3.5).

So if there's any way to sub \"wicens script\" for /jffs/addons/amtm/mail/email.conf line 5 FRIENDLY_ROUTER_NAME="RT-AX86U", that's my suggestion.

(Of course there are others that would probably prefer to know which app the notification is coming through, so others will probably want it left as is, and if you decide to leave it as is, I can just manually keep changing it.)
 
Hi, apologies if this has been answered, I did search the thread but couldn’t find a specific answer. I’m just dipping my toe into running scripts (I run Diversion Lite only).

I have a fixed WAN IP so would not work for what I would like it to do, but I was wondering if an option could be added that does a simple thing; just automatically send an Email on a reboot event, like a power failure?

thanks a lot

k.
 
I was wondering if an option could be added that does a simple thing; just automatically send an Email on a reboot event, like a power failure?
Maybe Version 4 if I ever get back into it

For now you can use this code and create an entry in services-start to accomplish a boot notification Email, still requires setting up wicens with your Email credentials, if WAN IP notifications are disabled you lose redundancy for failed Emails (no cron scheduled)

Copy and paste to /jffs/scripts/reboot-notify.sh and create/add the noted line to services-start, remember to run 'chmod a+rx /jffs/scripts/reboot-notify.sh' to make it executable

Code:
#!/bin/sh
# reboot-notification script for use with wicens, run this with services-start
# ie. in /jffs/scripts/services-start add the following line
# nohup sh /jffs/scripts/reboot-notify.sh >/dev/null 2>&1 &

# delay 45 secs after services-start runs
sleep 45

# handy print function
F_printf() { printf '%s\n' "$1" ;}

# log startup
logger -st "reboot-notify[$$]" "Creating reboot-notify.txt Email and starting wicens to send Email"

# create Email text in ram
{
        F_printf "Subject: Router has rebooted"
        F_printf "From: \"reboot-notify script\" <myfromaddr@gmail.com>"   # edit from address to your Email from address in wicens
        F_printf "Date: $(/bin/date -R)"
        F_printf "To: \"router user\" <mytoaddress@gmail.com>"   # edit to address to your Email send to address in wicens
        F_printf
        F_printf "NOTICE"
        F_printf
        F_printf "Your <insert router model here> router has restarted."
        F_printf
        F_printf "Current router time:$(uptime)"
        F_printf
        F_printf "A message from reboot-notify/wicens script"
} > /tmp/reboot-notify.txt

# call wicens as forwarder
nohup sh /jffs/scripts/wicens.sh send /tmp/reboot-notify.txt >/dev/null 2>&1 &

exit 0
 
[snip]

... create an entry in services-start ...... [snip]
Thank you very much, I will give it a go.

I don't currently have a services-start file but assume that wicens creates it on install.

Thanks again

k.
 

Attachments

  • ChMod.jpg
    ChMod.jpg
    163 KB · Views: 40
Maybe Version 4 if I ever get back into it

For now you can use this code and create an entry in services-start to accomplish a boot notification Email, still requires setting up wicens with your Email credentials, if WAN IP notifications are disabled you lose redundancy for failed Emails (no cron scheduled)

Copy and paste to /jffs/scripts/reboot-notify.sh and create/add the noted line to services-start, remember to run 'chmod a+rx /jffs/scripts/reboot-notify.sh' to make it executable

Code:
#!/bin/sh
# reboot-notification script for use with wicens, run this with services-start
# ie. in /jffs/scripts/services-start add the following line
# nohup sh /jffs/scripts/reboot-notify.sh >/dev/null 2>&1 &

# delay 45 secs after services-start runs
sleep 45

# handy print function
F_printf() { printf '%s\n' "$1" ;}

# log startup
logger -st "reboot-notify[$$]" "Creating reboot-notify.txt Email and starting wicens to send Email"

# create Email text in ram
{
        F_printf "Subject: Router has rebooted"
        F_printf "From: \"reboot-notify script\" <myfromaddr@gmail.com>"   # edit from address to your Email from address in wicens
        F_printf "Date: $(/bin/date -R)"
        F_printf "To: \"router user\" <mytoaddress@gmail.com>"   # edit to address to your Email send to address in wicens
        F_printf
        F_printf "NOTICE"
        F_printf
        F_printf "Your <insert router model here> router has restarted."
        F_printf
        F_printf "Current router time:$(uptime)"
        F_printf
        F_printf "A message from reboot-notify/wicens script"
} > /tmp/reboot-notify.txt

# call wicens as forwarder
nohup sh /jffs/scripts/wicens.sh send /tmp/reboot-notify.txt >/dev/null 2>&1 &

exit 0
Hi

Been using this for a while now and seems to work well, thanks once again.

If you were thinking to put it into the script it would be a nice addition for when I redo scripts after a clean firmware reset.

And if you were thinking to put it into the script a WAN Down option would be great too, in case the IP Address does not actually change :)

thanks!
 
Last edited:
Hi

Been using this for a while now and seems to work well, thanks once again.

If you were thinking to put it into the script it would be a nice addition for when I redo scripts after a clean firmware reset.
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
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top