NVRAM Variable not updating.

[Asad Ali]

Hmm then unfortunately it's out of my current knowledge, I can't help you more but wait a while, some other big guys will for sure lol.


Sent from my iPhone using Tapatalk

 

[Martineau]

/usr/sbin/ministun -t 1000 -c 1 -i tun13 stun.l.google.com:19302
Response read #0 timeout, retry

Sorry to state the obvious - I assume you are not blocking access to the servers?
e.g.

ping stun.l.google.com

PING stun.l.google.com (74.125.140.127): 56 data bytes
64 bytes from 74.125.140.127: seq=0 ttl=47 time=70.571 ms
64 bytes from 74.125.140.127: seq=1 ttl=47 time=12.742 ms
64 bytes from 74.125.140.127: seq=2 ttl=47 time=12.742 ms
64 bytes from 74.125.140.127: seq=3 ttl=47 time=12.737 ms
^C
--- stun.l.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 12.737/27.198/70.571 ms

..since you should always get a 'non-timeout' response even if the tun1x isn't UP

/usr/sbin/ministun -t 1000 -c 1 -i tun13 stun.l.google.com:19302
Bind socket to device [tun13] failed! errno 19 (No such device)
78.xxx.xxx.xxx

My cron script checks that the NVRAM variable actually matches the current physical tunnel IP by calling the /usr/sbin/gettunnelip.sh script

./VPN_Client_Switch.sh status

VPN Client Status:
          Client 1 Connected via 100.120.56.153 (HMA New York)                    VPN tunnel end-point I/P: 77.234.46.197
          Checking for response (5secs) from 'http://ipecho.net/plain' to verify  VPN tunnel end-point I/P: 77.234.46.197
                                                                                  VPN tunnel end-point I/P: 77.234.46.197

then uses this method to retrieve the comparison value:

curl --connect-timeout 5 -s --interface "tun1"${VPNID} "http://ipecho.net/plain"

 

[DFFRZ]

Ping works fine:

ping -c 4 stun.l.google.com
PING stun.l.google.com (64.233.177.127): 56 data bytes
64 bytes from 64.233.177.127: seq=0 ttl=45 time=7.559 ms
64 bytes from 64.233.177.127: seq=1 ttl=45 time=7.844 ms
64 bytes from 64.233.177.127: seq=2 ttl=45 time=7.536 ms
64 bytes from 64.233.177.127: seq=3 ttl=45 time=7.665 ms
--- stun.l.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 7.536/7.651/7.844 ms

Ping also works using the tun13 interface:

ping -c 4 -I tun13 stun.l.google.com
PING stun.l.google.com (64.233.177.127): 56 data bytes
64 bytes from 64.233.177.127: seq=0 ttl=47 time=30.757 ms
64 bytes from 64.233.177.127: seq=1 ttl=47 time=31.356 ms
64 bytes from 64.233.177.127: seq=2 ttl=47 time=31.140 ms
64 bytes from 64.233.177.127: seq=3 ttl=47 time=30.801 ms
--- stun.l.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 30.757/31.013/31.356 ms

Your curl code returns the correct IP: (response partially masked in post by me)

curl --connect-timeout 5 -s --interface "tun13" "http://ipecho.net/plain"
209.160.119.xxx

ministun fails:

/usr/sbin/ministun -t 1000 -c 1 -i tun13 stun.l.google.com:19302
Response read #0 timeout, retry

 

[Martineau]

Your curl code returns the correct IP: (response partially masked in post by me)

curl --connect-timeout 5 -s --interface "tun13" "http://ipecho.net/plain"
209.160.119.xxx

Well fortunately at least you now have a solution for your original e-mail notification requirements.

ministun fails:

/usr/sbin/ministun -t 1000 -c 1 -i tun13 stun.l.google.com:19302
Response read #0 timeout, retry

https://gist.github.com/zziuni/3741933 ​

Telling question dated 29th Aug.

"Does any one have any idea what to do if google stun is not available ?! Can we refer to any support or something !"

So I suspect that is why @RMerlin specifies two stun servers, so it's probably simply bad luck if both simultaneously fail, but you/@RMerlin can patch the script to include any of the others listed although they can present spurious result text
e.g. stun.wtfismyip.com

/usr/sbin/ministun -t 1000 -c 1 -i tun11 stun.wtfismyip.com
Runt Attribute (got 2, expecting 4)
77.234.46.197

 

[DFFRZ]

I think ministun has a bug running on the RT-AC68P because stun.wtfismyip.com fails also:

/usr/sbin/ministun -t 1000 -c 1 -i tun13 stun.wtfismyip.com
Response read #0 timeout, retry

 

[john9527]

Where are you calling ministun from? There is something going on that prevents ministun from working if it's called from other than the user shell environment (i.e. by the openvpn initiated scripts like openvpn-event or even if it's an embedded system call in the mainline openvpn c code). I ran into this while working on my fork, and wasn't able to figure out why it failed.

 

[DFFRZ]

Invoked directly at the SSH prompt and also in a script (which was invoked at the shell prompt).

Failed, as shown above, in both cases.

 

[maxiarg14]

Hi @DFFRZ, @Asad Ali

Did you find any solution for this issue? Exactly the same thing is happening to me. I tried the curl command suggested by @Martineau too, but is still not working. It seems that ip is seted after this line in the log is executed: "Initialization Sequence Completed".

Thanks!
Regards!

 

[maxiarg14]

@Martineau, @RMerlin do you have any other suggestion? The curl command is start working after "Initialization Sequence Completed", the same if I call "usr/sbin/gettunnelip.sh". Both commands starts to work after the initialization is completed, no matter what sleep delay I set, so I can't get the ip before the initialization event.

Thank you very much.
Regards.

 

[Asad Ali]

Hi @DFFRZ, @Asad Ali

Did you find any solution for this issue? Exactly the same thing is happening to me. I tried the curl command suggested by @Martineau too, but is still not working. It seems that ip is seted after this line in the log is executed: "Initialization Sequence Completed".

Thanks!
Regards!

You have to call the "gettunnelip" script from inside your script first to let it initialize the NVRAM variable.

Put this line on top of your script :

sh /usr/sbin/gettunnelip.sh 1

Change the digit as per your VPN cleint. 1 is for VPN client number 1.

 

[maxiarg14]

You have to call the "gettunnelip" script from inside your script first to let it initialize the NVRAM variable.

Put this line on top of your script :

sh /usr/sbin/gettunnelip.sh 1

Change the digit as per your VPN cleint. 1 is for VPN client number 1.

@Asad Ali Thanks for answer. Yes, that is what I´m doing, but for some reason that command is not working until the line "Initialization Sequence Completed" appears in the log, so when running the script "usr/sbin/gettunnelip" from inside my script, it returns an "unkown" ip. Now I'm not at home, but in a few hours I will post my script, so you can see it. Maybe I´m doing something wrong.

Regards

 

[lahma]

@Asad Ali Thanks for answer. Yes, that is what I´m doing, but for some reason that command is not working until the line "Initialization Sequence Completed" appears in the log, so when running the script "usr/sbin/gettunnelip" from inside my script, it returns an "unkown" ip. Now I'm not at home, but in a few hours I will post my script, so you can see it. Maybe I´m doing something wrong.

Regards

This same things is happening to me as well. Running 'sh /usr/sbin/gettunnelip.sh 1' or 'curl --connect-timeout 5 -s --interface "tun11" "http://icanhazip.com"' in my ssh shell works perfectly fine but if I try to run these commands within any of my openvpn-event scripts, regardless of the sleep delay, it simply does not work. It has to be something related to the process that is executing the script. I've been messing with this for the last 8 hours and I am SO frustrated. Did you ever figure this out @maxiarg14 or anyone else?

Edit: To be clear, the commands won't work in my ssh shell until the following message appears in my log (which doesn't appear until AFTER the openvpn-event scripts are finished running):

ovpn-client1[775]: Initialization Sequence Completed

The same exact behavior @maxiarg14 is seeing.

Edit #2: My guess is that this has something to do with the "Block router clients if tunnel goes down" setting... I'm assuming this is blocking any traffic, including anything run inside the openvpn-event scripts, until after they are finished running. Kind of defeats the purpose of having an 'vpnclient1-route-up' script though if all of the routes are not actually 'up'...

 

[john9527]

Yes, I spent a lot of time trying to figure out why gettunnelip doesn't work in a script called from openvpn...never could. Luckily there's an alternative. Openvpn sets an environment variable with the VPN endpoint address accessible from called openvpn scripts. Access it as

$trusted_ip

 

[lahma]

Yes, I spent a lot of time trying to figure out why gettunnelip doesn't work in a script called from openvpn...never could. Luckily there's an alternative. Openvpn sets an environment variable with the VPN endpoint address accessible from called openvpn scripts. Access it as

$trusted_ip

Thanks for the quick reply! That is interesting... I tried typing 'echo $trusted_ip' into my shell and it appears to be invalid/blank (and my VPN client is currently active). Ultimately, I came up with a workaround which is working fine but I still wish there was a better way of tackling the issue. For anyone coming across this thread in the future, my workaround is as follows:

Note: My goal was to be able to update my DDNS address (a different one than the one configured in the router GUI for my WAN IP) to my VPN client's exit IP every time the router reestablishes a connection to my VPN provider. Obviously, this is the type of thing that the 'openvpn-event' scripts (vpnclient1-up/vpnclient1-route-up) were made for but ultimately, anything in those scripts that requires network communication (internet) simply does not work (most likely because of the "Block router clients if tunnel goes down" setting in the VPN client GUI) because the router blocks all internet traffic until after these scripts are finished executing. Furthermore, even if I was able to somehow get the VPN client exit IP within one of these scripts, I most likely still wouldn't be able to issue the 'wget' command needed to contact my DDNS provider's API to update my DDNS address IP.

The somewhat hackish solution I came up with was to create a cron job in my 'vpnclient1-route-up' script which calls a separate script that updates my DDNS address. This works around the issue by having my script run AFTER the VPN client initialization is complete, which means my script has no issues with accessing the internet. I've provided simplified examples of my 2 scripts below: vpnclient1-route-up (responsible for creating the cron job using cru) and vpnclient1-ddns-update (the script that the cron job executes which is responsible for retrieving my VPN client exit IP and updating my DDNS address).

vpnclient1-route-up

#!/bin/sh

# ------------------------------------------------------------------------
# Script Info:
# ------------------------------------------------------------------------
# Sets up a cron job to run the script that updates the DDNS address
# '****.*****.***'; it has to be done this way bc all network
# communication in any openvpn-event script fails until AFTER they are
# finished running
# ------------------------------------------------------------------------

scr_name="$(basename "$0")[$$]"
vpn_num=$(echo $(basename "$0") | grep -o -E "[0-9]+")
logger -t "$scr_name" "VpnClient${vpn_num} - Running vpnclient${vpn_num}-route-up script"

# Ensures existing cron job is deleted
cru d "vpnc${vpn_num}ddns"

# Adds a cron job to run the 'vpnclient1-ddns-update' script AFTER VPN initialization is complete
logger -t "$scr_name" "VpnClient${vpn_num} - Adding cron job 'vpnc${vpn_num}ddns' to run 'vpnclient${vpn_num}-ddns-update' within the next min"
cru a "vpnc${vpn_num}ddns" "* * * * * /jffs/scripts/vpnclient${vpn_num}-ddns-update"

vpnclient1-ddns-update

#!/bin/sh

# ------------------------------------------------------------------------
# Script Info
# ------------------------------------------------------------------------
# Responsible for updating DDNS '****.*****.***' with the exit IP
# of VPN Client #1 via DynU.com's API; this script is executed via a
# cron job created in the 'vpnclient1-route-up' script
# ------------------------------------------------------------------------

scr_name="$(basename "$0")[$$]"
vpn_num=$(echo $(basename "$0") | grep -o -E "[0-9]+")
logger -t "$scr_name" "VpnClient${vpn_num} - Running $(basename "$0") script"

# Deletes cron job so it does not repeat
logger -t "$scr_name" "VpnClient${vpn_num} - Deleting cron job 'vpnc${vpn_num}ddns'"
cru d "vpnc${vpn_num}ddns"

# ------------------------------------------------------------------------
# Retrieves VPN Client #1 exit IP address
# ------------------------------------------------------------------------
logger -t "$scr_name" "Running 'gettunnelip.sh' to update nvram variable 'vpn_client${vpn_num}_rip'"
sh /usr/sbin/gettunnelip.sh $vpn_num
ip=$(nvram get vpn_client${vpn_num}_rip)

# ------------------------------------------------------------------------
# Another way to do the above task
# ------------------------------------------------------------------------
# intfc="tun1${vpn_num}"
# logger -t "$scr_name" "Running curl cmd to get exit IP address of interface $intfc"
# ip=$(curl --connect-timeout 5 -s --interface "${intfc}" "http://icanhazip.com")
# logger -t "$scr_name" "VPN Client #${vpn_num} exit IP is '${ip}'"

# ------------------------------------------------------------------------
# Dynu.com DDNS - Set '****.*****.***' to VPN Client #1 exit IP
# ------------------------------------------------------------------------
if    [ "$ip" != "0.0.0.0" ] \
   && [ "$ip" != "unknown" ] \
   && [ "$ip" != "" ] ; then
  hostname="****.*****.***"
  nvram set "vpn_client${vpn_num}_rip"=$ip # Not needed if you got IP by running 'gettunnelip.sh'
  logger -t "$scr_name" "Updating DDNS '${hostname}' to VPN Client #${vpn_num} exit IP '${ip}'"
  wget -O/dev/null -q "https://api.dynu.com/nic/update?hostname=${hostname}&myip=${ip}&myipv6=no&password=**************************"
fi

 

[john9527]

I tried typing 'echo $trusted_ip' into my shell and it appears to be invalid/blank (and my VPN client is currently active).

Openvpn sets an environment variable with the VPN endpoint address accessible from called openvpn scripts.

It's only active in the environment when running scripts spawned by openvpn. In the Merlin context, that means a script tied to openvpn-event. Just openvpn running/trying in a shell won't work.

 

[lahma]

It's only active in the environment when running scripts spawned by openvpn. In the Merlin context, that means a script tied to openvpn-event. Just openvpn running/trying in a shell won't work.

Ah, gotcha. Thanks for the info!