The actual versions of update scripts do no longer need a manual configuration of the HOPS variable!
The documentation at DynDN.eS uses the term HOPS together with our update scripts. For all who are not familiar with this term I do explain it here a bit more in detail - always related to our service. Afterwards it should not be a problem to set the correct HOPS value in the update scripts.
In general a hop is point (router) on the way to a destination. The tool to check the hops is traceroute (or tracert
on Windows). An example to determine the number of hops:
$> traceroute -n -q 1 google.com traceroute to google.de (74.125.232.1), 30 hops max, 60 byte packets 1 109.238.24.253 11.222 ms 2 80.67.18.129 0.994 ms 3 80.67.29.154 0.985 ms 4 194.59.190.61 1.491 ms 5 66.249.94.86 1.663 ms 6 216.239.47.189 1.900 ms 7 74.125.232.1 1.585 ms
There are 7 hops from the local computer to the destination “google.com”. Each hops represents a router (except the last one).
What do we call a router? A router is a machine with more than one network connection. So it can route data between the networks. In the example below you can see the incoming IP address of each of these routers. The outgoing address is impossible, but the last IP address is the one of the destination.
This ist the trick. We want to set the number of hops to the external ip address.
Maybe an example makes it more clear. Lets define that the internal network is 172.17.0.0/16. The (dsl) router has internal IP 172.16.0.1 and our computer has IP 172.16.0.2. Further lets define the external IP is 87.89.65.157 and we have a dynamic hostname example.us.dyndn.es created. Open a shell (command prompt):
$> traceroute -n -q 1 87.89.65.157 traceroute to 87.89.65.157 (87.89.65.157), 30 hops max, 60 byte packets 1 172.16.0.1 0.280 ms 2 87.89.65.157 1.027 ms
You see that the second hop - or better lets say the last hop - is exactly the external IP. So the value of 'HOPS' have to be set to 2 in this case.
In practice it works because we check the last good (saved) IP by using the option -m 2 to limit the number of hops:
$> traceroute -n -q 1 -m 2 87.89.65.157 traceroute to 87.89.65.157 (87.89.65.157), 2 hops max, 60 byte packets 1 172.16.0.1 0.280 ms 2 87.89.65.157 1.027 ms
Determine carefully the output of the last two examples (hint: second line, “X” hops max). Otherwise all is exactly the same!
Back to the trick. If the dynamic IP was changed, the last hop (as destination) has a different IP against the last saved one - an update of the dynamic hostname have to be triggered by the script.
Just an example how the equivalent tracert works under Windows (note: we use the dynamic hostname instead of the IP address here):
C:\> tracert -d -h 2 example.us.dyndn.es
Tracing route to example.us.dyndn.es [87.89.65.157] over a maximum of 2 hops:
1 5 ms 1 ms <1 ms 172.16.0.1
2 1 ms 1 ms <1 ms 87.89.65.157
Trace complete.
The options are different but do the same.
The decision to determine the external IP this way was done far in the past. We have had quite often a configuration with a (dsl) router and a server behind. The issue was that the functionality to use a dynamic DNS was different between router models and sometimes unusable. With this solution we can check the dynamic IP local and remote in any case.
Checking the IP internally before trying to update saves resources on web services. In our experience this process runs stable for the given scenario with very rarely exceptions.