Print

[fmayhar]

I've long been depending on (a close derivation of) the tunnelbroker-update perl script available here.  Recently, though, it broke due to a change to the web page (boldfacing the network bits, sigh).  So I fixed it, in the process adding a dependency on HTML::Strip.  I've re-versioned it as 0.11 and have attached it to this post.  It Works For Me, no warranty expressed or implied, no user-serviceable parts inside, void where prohibited, etc. etc.

Enjoy.

[kcochran]

This script would have actually broken quite a while ago when the <b> tags were added to the v6 addresses in the hopes of people noticing the variance in them.

That said, you're going to hate me.  That page will be changing yet again, and a bit more of a shift than before.  However, there's now a new means of pulling the data, and this format isn't due for changing anytime soon.

https://username:password@tunnelbroker.net/tunnelInfo.php[?tid=tunnel_id]  The option is... optional.  Username and password are in the clear, but it is over HTTPS, and this mechanism lines up with the dyndns methods, but this data is read-only.

The return will be a XML formatted output of your tunnel specifics, similar to the following.  If you pass the tid, you'll only get the one tunnel's data.

Code: [Select]

<?xml version="1.0" encoding="UTF-8"?>
<tunnels>
 <tunnel id="###">
  <description>Demo</description>
  <serverv4>72.52.104.74</serverv4>
  <clientv4>10.2.2.2</clientv4>
  <serverv6>2001:db8:1::1</serverv6>
  <clientv6>2001:db8:1::2</clientv6>
  <routed64>2001:db8:2::/64</routed64>
  <routed48>2001:db8:3::/48</routed48>
  <rdns1>ns1.he.net</rdns1>
  <rdns2>ns2.he.net</rdns2>
  <rdns3>ns3.he.net</rdns3>
  <rdns4>ns4.he.net</rdns4>
  <rdns5>ns5.he.net</rdns5>
 </tunnel>
</tunnels>


[fmayhar]

Yeah, it had broken a long time ago.  I've been rather preoccupied with other things.

Sigh.  Yes, I hate you.  I noticed that the script was broken today and now I have to fix it again.

XML?  Siiiigh.

So have the update pages changed?  That is, ipv4_end.php and nsupdate.php?

OBTW, losing the md5sum for the password in favor of in-the-clear passwords (despite being encrypted via SSL) means that the script will also have to have the password in the clear.  This is generally regarded as not such a good thing.  At least the md5sum provided a little obfuscation, anyway.

[kcochran]

While XML may be verbose, it's at least a fixed format and has parsers out the nose to deal with it.  Was either that or JSON for the data representation.

ipv4_end.php works as before.  The usage output it throws out uses a different structure, but it'll happily work with existing scripts.  Output is also prefixes with -ERROR or +OK.

There's a new script to do nsupdate.php off the detail page named edit_rnds.php, but it'll be renamed over to nsupdate.php soon, as it'll operate in a similar fashion.  There's just some temporary technical reasons for the old one to still be in place for the moment.  I'd whip up something less page-scrapey to manage it if it seemed people needed it.  rDNS delegation isn't something that tends to need to get switched much, let alone from an automatic script.

While md5 is a little less useful if someone got it from you, finding a match for it isn't too tough these days with how much cheap computation time is available.  It's about as secure as storing it in the script using some symmetric cipher.  Using the raw password (but only ever over SSL) also lets us change how we store it in the future.  Kind of tough to switch a password database to another cipher when the only thing you have to work with is the ciphered value.

There are a couple more changes in the pipe, but they're not involved with tunnel updates.

[onley]

First and foremost, Thank You for doing all you do here, I've learned a ton about IPv6 in short order by being able to actually work with it.

You used to get to a page with the documentation for this when you clicked on your IPv4 address on the Tunnel Details page but now you get an entry box to update right there on the Tunnel Details page. Is it still possible to get to the documentation page somehow?  Also the error message that comes up has what appear to be some typos, I've marked what doesn't seem quite right in red below, apologies if I am reading something wrong.


-ERROR: Missing parameter(s).
Usage: https://ipv4.ipv4.tunnelbroker.net/ipv4_end.php?ip=IPV4ADDR&pass=MD5PASS&apikey=USERID&tid=TUNNELID
-or-: https://USERNAME:PASSWORD@ipv4.ipv4.tunnelbroker.net/ipv4_end.php?tid=TUNNELID (auto-detect IP)
https://USERNAME:PASSWORD@ipv4.ipv4.tunnelbroker.net/ipv4_end.php?tid=TUNNELID&ip=IPV4ADDR (auto-detect IP)

[kcochran]

Extra ipv4. was due to how it was generating the hostname for the URL.  That's now fixed.

I've added in a link to the ipv4_end.php page on the help for the "Client IPv4 Endpoint"

[onley]

Again, Thank You

I wish there was some way I could give something back.

[fmayhar]

Lots of good info.
There are a couple more changes in the pipe, but they're not involved with tunnel updates.

Thanks very much for the information.  I'm a bit under the weather at the moment but I'll try to get these changes in as soon as I'm up to it.

[cessnaflyer]

I hope this saves someone the trouble it caused me:

If you're trying to use wget to access the tunnelInfo.php page, you will need the --auth-no-challenge option to force wget to send your credentials unsolicited.