Tunnel Broker Inactivity / IPv4 address update

[theckman]

Greetings,

I did a quick search on the forums but I seemed to fail at locating a thread that seemed to address both of my questions.  I've used an old netbook to create an IPv6 gateway at home on Debian Squeeze. (Here's the article I wrote explaining the process if anyone is interested: http://blog.timheckman.net/2011/05/24/he-tunnelbroker-ipv6-gateway/)  I was at work this evening and was going to connect to my IPv6 gateway at home.  However, I quickly noticed that the tunnel seemed to have gone down.  A coworker mentioned the tunnel may not remain open if there is not network connectivity going across it.  I will be building a timed script to run and ping a known working IPv6 host every so often to keep the tunnel open.  Anyone know what the timeout is by chance?

The second question is regarding the IPv4 update function (as explained here: http://ipv4.tunnelbroker.net/ipv4_end.php).  I'm thinking of writing a BASH script to update my IPv4 endpoint as needed.  However, I don't want to hit the update too often and I do have a question about the process by which the IPv4 is updated.  I'm not planning on hitting that API once every minute or something crazy, but would "poking" it every fifteen minutes be an issue?  If I do have the script hit the page once an hour, is the API smart enough to realize new IPv4 == old IPv4 and not do anything, or does it update the tunnel anyway.  Could this affect my connection if it does update anyway?

Thank in advance!

-Tim

[kcochran]

Tunnels are stateless, so any inactivity timer is normally going to be something in the middle, like certain firewalls.  If it doesn't see proto 41 from inside->outside, it might not send it back inside after a while.

As to endpoint updates, if the endpoint matches, it kicks back before even touching the tserv.  Usually the place to put that would be in your ifup scripts (if the tunnel is anchored on your gateway system, and therefore would know if your public IP changed), or saving what your current IP is and checking if it has changed prior to making a timed update.

[theckman]

Tunnels are stateless, so any inactivity timer is normally going to be something in the middle, like certain firewalls.  If it doesn't see proto 41 from inside->outside, it might not send it back inside after a while.

As to endpoint updates, if the endpoint matches, it kicks back before even touching the tserv.  Usually the place to put that would be in your ifup scripts (if the tunnel is anchored on your gateway system, and therefore would know if your public IP changed), or saving what your current IP is and checking if it has changed prior to making a timed update.

My gateway is running a minimal version of DD-WRT due to internal storage constraints.  As such, I've had to throw Debian server on my spare netbook.  I've not been able to replicate a scenario where the external IP changes to see if it will notice. I do already have the script on my networking configuration that runs when the network is brought up.  I guess what I'll be doing is checking the external IP address, validating it against a cached copy, and then push to the ipv4 update API if a change does indeed happen.

Thank you for the information you've provided!

-Tim