Dynamic Endpoint Update not working

[KlaasT]

Hi,

I have an issue with the update of the dynamic endpoints. When I use https://<USERNAME>:<PASSWORD>@ipv4.tunnelbroker.net/nic/update?hostname=<TUNNEL_ID> it will give me "badip". I always have to specify a valid IP Address. Is there another way to update the endpoint?

Thanks.

[KlaasT]

Hm. Does anyone have an advice on this?

[cholzhauer]

Do you know why its giving an error in the first place?

I've never used the service

[Ninho]

https://<USERNAME>:<PASSWORD>@ipv4.tunnelbroker.net/nic/update?hostname=<TUNNEL_ID>

You tried to use basic HTTP authentication, that won't work.
Either use a browser to visit the tunnel broker page and update your IP address manually, or if you really want to automate the update, you should use an URL such as :

"https://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=AUTO&pass=777777777777777777777777777777777&user_id=88888888888888888888888888888888&tunnel_id=32223"

... replacing °your° tunnel ID and (base64 encoded MD5 hashed username and password.

[KlaasT]

Hm... Ok thanks. I'll try that. Then I didn't really understand the news about the new method for dynamic endpoint updates.

[Ninho]

Hm... Ok thanks. I'll try that. Then I didn't really understand the news about the new method for dynamic endpoint updates.

What I outlined above is the /older/ (good old :)  as in works for me, using wget) method. I have not looked into other methods, in fact hardly noticed there was a new one - my bad, I'm known for not liking new things very much <G>

[swschulz]

Did you ever get this to work?  Since I'm using RoadRunner and it disconnects several times per day now, I have to update my endpoint multiple times per day.  I wrote a little script to call the new update routine with wget, but I too constantly receive the 'badip' result, and end up having to update the endpoint by hand anyway.

Thanks.

[KlaasT]

Oh yes. Sorry I didn't mention that it works now. I switched back to the "good old way" and this works far better than the new way.

[kcochran]

"badip" gets returned in a bunch of cases, which aren't always due to a bad ip per-se.  Just a limitation of the error types returnable by something that's Dyn-compatible.  If there was a mechanism to append supplemental information (akin to SMTP's extended status codes: "550 5.7.1 Useful text here"), we would be using it.

Back to "badip".  You'll get this if any of the following occur:

• Invalid IP address format
• No 'myip' variable set, and somehow the server couldn't figure out the connecting address (unlikely)
• Trying to update endpoint to an IPv6 address (ensure you're using ipv4.tunnelbroker.net/nic/update to keep this from happening)
• IP is already assigned to a different tunnel (you'll get nochg if it's the tunnel you're currently trying to update)
• IP isn't pingable

[kasperd]

Can you tell me what will happen in the following scenario?

User1 with a dynamic IPv4 address goes online and updates his IPv4 endpoint address, and after a little while goes offline again with the tunnel still configured.
User2 who also have a dynamic IPv4 address goes online and happens to get the same IPv4 address that User1 had before.
User2 tries to update his IPv4 endpoint address.

Is this going to succeed, or will User2 get an error because his IPv4 address is already configured as the endpoint belonging to User1 (who is currently offline)?

I don't see any technical reason for the constraint that two tunnels cannot share the IPv4 endpoint on the user side. If you were to remove that restriction, I think it would just work. It might be that software on the user side cannot deal correctly with this and most users will be using software that could only ever have one of the two tunnels work correctly. But even so, I don't think any simple heuristic on the HE side could figure out which of the two tunnels is the correct one to have the IPv4 address. If your heuristic gets it wrong, the tunnel would have been working won't work. If you were to just permit both, at least the tunnel for which the IPv4 address is correct will work.

Assuming you have 2^17 tunnels with dynamic IPv4 address, and half of them are online and the other half are offline, there is a significant probability of a collision of the IPv4 address between one of the users currently online and one of the users currently offline. Assuming your tunnel IDs are assigned sequentially, you have way more than 2^17 tunnels configured, but of course I don't know what percentage of those are online at any given time, and I don't know how dynamic the IP addresses are. You certainly have enough tunnels that the scenario I described is likely going to happen at some point.

[swschulz]

Back to "badip".  You'll get this if any of the following occur:

• No 'myip' variable set, and somehow the server couldn't figure out the connecting address (unlikely)
• IP isn't pingable

Okay, thank you.  I have been using the autodetermine IP method and it has been failing, but now I see it is because my external address isn't pingable.

I added a little PHP script to output REMOTE_ADDR to a server, and I call that in my update script now so it will have the ability to set myip= in the script.

Thanks for the clarification.

SwS

[paulbearddotorg]

Can anyone verify that any of these methods actually work?

Just to show these are actual values without posting them:

Code Select Expand

echo ${TUNNELPASS} ${USERID} | wc
      1       2      30


I get a lot of this:

Code Select Expand


curl -k "https://ipv4.tunnelbroker.net/ipv4_end.php?pass=${TUNNELPASS}&apikey=${USERID}&tid=157062"
-ERROR: Invalid API key or password


It would be helpful if this

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

didn't use various names for the same variables (which is it: apikey, username, or userid? How about pass or password or md5pass?) And are both the authentication credentials supposed to base64 encoded?

This is what I use to generate the base64 tokens (though with the real values, of course):

Code Select Expand


echo -n userid | openssl enc -base64


UPDATE: the only method that *seems* to work (i.e., it doesn't kick back an error and complains about a needless update) is use the embedded plaintext username and password. Granted it's over https but again, it's not like the documentation specifies where plaintext vs encoded credentials are to be used.

I'll see if it works when my IP address is changed.

[kasperd]

didn't use various names for the same variables (which is it: apikey, username, or userid? How about pass or password or md5pass?) And are both the authentication credentials supposed to base64 encoded?

I am using ipv4b, pass, user_id, and tunnel_id. That combination still works, though the new names may be the preferred approach. With the combination of parameters that I specify nothing needs to be base64 encoded. The pass parameter is the md5sum of the actual password (in the usual hexadecimal encoding).

Granted it's over https but again, it's not like the documentation specifies where plaintext vs encoded credentials are to be used.

And in reality none of those actually gives security. Applying base64 encoding wouldn't be for security reasons, but just to cover the case of passwords containing special characters. Using an md5sum of the password means somebody listening won't be able to use it to log in on the websites, but they could still use the md5sum they sniffed to change your tunnel endpoint. And as for the ssl part, remember that the -k argument you give to curl is really just another name for --insecure.

If you want a little bit of security for such updates without having a real SSL certificate, at least use an HMAC on a timestamp and the new IPv4 address instead of just a hash of the password. You can do HMAC with a couple of lines of shell script (or at least something that is equivalent securitywise).

[paulbearddotorg]

I learned about what curl -k does this morning while trying to solve another problem (ftp transfers over IPv6 are problematic in FreeBSD). So yeah, that's helpful </snark>

If what I have works, I'll leave it alone. If not I'll revisit your comment. I think what you use was one of the many variations I tried. I suspect, as many times as this seems to have come up, that someone at HE could add the necessary incantation to the tunnel details page. Shame on me for using my own address checker/DNS updater (couldn't understand the various public domain clients), I guess.