What's new

384.9 DDNS problem

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Bob Pilette Jr

New Around Here
I have a RT-AC3200 that had 384.6 firmware on it. When I updated to 384.9 firmware my DDNS with www.tunnelbroker.net quit working. I checked my logs and tunnelbroker was sending "[401 NI] badauth". I downgraded to 384.6 and the problem went away. I did not factory reset because the DDNS entries are not obviously listed at tunnelbroker so I need to look up where they are again if you want me to try a factory reset with 384.9.
 
Inadyn probably uses a newer API. You need to provide the Tunnel ID, Account Name, and Update Key (NOT the password).
 
The page did not change from what I saw. All the values were still in there but the password (update key) was dotted out of course. I tried pasting in the update key again that tunnelbroker had on my tunnel page advanced tab since I could not see the value in 384.9 but that did not change anything because I still had the error when I clicked apply after doing that.
 
The newer API that Inadyn uses is probably why even though the values seem to be there on the page, they are not being used the same way with the 384.9 firmware.

You can best test with a reset to factory defaults (make sure to also wipe out the jffs partition too after you have saved any important info/files it contains) by using the GUI checkbox to 'initialize all settings...'.

This is especially true if you haven't performed a full reset to factory defaults for several firmware updates that you may have done.
 
....,

This is especially true if you haven't performed a full reset to factory defaults for several firmware updates that you may have done.
Assuming one’s updated every time Merlin’s brought out a new update and there hasn’t been a mandatory reset in between, do you have a personal rule of thumb for how many updates you’d let go by before resetting, or would it depend on what you’ve noted in the changelogs? Or perhaps if there are no issues you leave well alone but at the first sign of a glitch you decide enough updates have gone by, time to reset?
 
Assuming one’s updated every time Merlin’s brought out a new update and there hasn’t been a mandatory reset in between, do you have a personal rule of thumb for how many updates you’d let go by before resetting, or would it depend on what you’ve noted in the changelogs? Or perhaps if there are no issues you leave well alone but at the first sign of a glitch you decide enough updates have gone by, time to reset?

I used to religiously do a factory reset when I was in 'testing' mode a few years ago. I was already wasting too much time I didn't have then to be introducing glitches myself by not doing so.

Today, I'm more inclined to do a dirty update to my own routers and keep careful track of any anomalies I notice. For customers though, I do a full and proper reset to defaults because I want to be done when I walk out their door unless there is a real issue to track down. And even if there is, I am able to begin troubleshooting right away as I would have already put their router into the best 'good/known' state possible.
 
I used to religiously do a factory reset when I was in 'testing' mode a few years ago. I was already wasting too much time I didn't have then to be introducing glitches myself by not doing so.

Today, I'm more inclined to do a dirty update to my own routers and keep careful track of any anomalies I notice. For customers though, I do a full and proper reset to defaults because I want to be done when I walk out their door unless there is a real issue to track down. And even if there is, I am able to begin troubleshooting right away as I would have already put their router into the best 'good/known' state possible.
Many thanks. Until I read your answer, I used to think the phrase “dirty upgrade” a bit harsh, but you’ve really put it into perspective. Much appreciated.
 
Updated my firmware to 348.9 and did a complete initialization to factory settings and clearing logs. Then I went down the pages and only changed what I needed to to secure the router and set up DDNS. I copied and pasted the values from HE tunnelbroker pages I preloaded on my desktop and as soon as I clicked apply and it came back I had an error. Here is a copy of that part of my log with identifying numbers ? out.

Mar 12 15:04:50 start_ddns: update WWW.TUNNELBROKER.NET default@tunnelbroker.net, wan_unit 0
Mar 12 15:04:51 dhcp_client: bound ??.???.???.??? via ??.???.???.? during 3600 seconds.
Mar 12 15:04:51 inadyn[1096]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Mar 12 15:04:52 inadyn[1096]: Update forced for alias ??????, new IP# ??.???.???.???
Mar 12 15:04:54 inadyn[1096]: Fatal error in DDNS server response:
Mar 12 15:04:54 inadyn[1096]: [401 NI] badauth
Mar 12 15:04:54 inadyn[1096]: Error response from DDNS server, exiting!
Mar 12 15:04:54 syslog: Error code 48: DDNS server response not OK

Then I downgraded the firmware back to 348.6 and DDNS worked OK so the values must be correct. Here is the log from that with identifying numbers ? out.

Mar 12 15:28:57 ddns_update: request successful: Tunnel endpoint updated to: ??.???.???.???
Mar 12 15:28:57 ddns_update: asusddns_update: 0
Mar 12 15:28:58 ddns: ddns update ok
Mar 12 15:28:58 ddns_update: exit_main
Mar 12 15:29:12 watchdog: start ddns.
Mar 12 15:29:12 rc_service: watchdog 284:notify_rc restart_ddns
Mar 12 15:29:13 start_ddns: update WWW.TUNNELBROKER.NET heipv6tb, wan_unit 0
Mar 12 15:29:13 ddns_update: ez-ipupdate: starting...
Mar 12 15:29:13 ddns_update: connected to ipv4.tunnelbroker.net (64.62.200.2) on port 80.
Mar 12 15:29:14 ddns_update: request successful: This tunnel is already associated with this IP address. Please try to limit your updates to IP changes.
Mar 12 15:29:14 ddns_update: asusddns_update: 0
Mar 12 15:29:14 ddns: ddns update ok
Mar 12 15:29:14 ddns_update: exit_main

Looks like inadyn and tunnelbroker do not play nice together or something in the www.tunnelbroker.net preset is wrong for at least 348.9 and maybe even 348.7 and 347.8 since I did not try those.

What do you think RMerlin? I will stay on 348.6 until you find out what is happening and if you think you have a fix I am willing to try it for you.
 
Updated my firmware to 348.9 and did a complete initialization to factory settings and clearing logs. Then I went down the pages and only changed what I needed to to secure the router and set up DDNS. I copied and pasted the values from HE tunnelbroker pages I preloaded on my desktop and as soon as I clicked apply and it came back I had an error. Here is a copy of that part of my log with identifying numbers ? out.

Mar 12 15:04:50 start_ddns: update WWW.TUNNELBROKER.NET default@tunnelbroker.net, wan_unit 0
Mar 12 15:04:51 dhcp_client: bound ??.???.???.??? via ??.???.???.? during 3600 seconds.
Mar 12 15:04:51 inadyn[1096]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Mar 12 15:04:52 inadyn[1096]: Update forced for alias ??????, new IP# ??.???.???.???
Mar 12 15:04:54 inadyn[1096]: Fatal error in DDNS server response:
Mar 12 15:04:54 inadyn[1096]: [401 NI] badauth
Mar 12 15:04:54 inadyn[1096]: Error response from DDNS server, exiting!
Mar 12 15:04:54 syslog: Error code 48: DDNS server response not OK

Then I downgraded the firmware back to 348.6 and DDNS worked OK so the values must be correct. Here is the log from that with identifying numbers ? out.

Mar 12 15:28:57 ddns_update: request successful: Tunnel endpoint updated to: ??.???.???.???
Mar 12 15:28:57 ddns_update: asusddns_update: 0
Mar 12 15:28:58 ddns: ddns update ok
Mar 12 15:28:58 ddns_update: exit_main
Mar 12 15:29:12 watchdog: start ddns.
Mar 12 15:29:12 rc_service: watchdog 284:notify_rc restart_ddns
Mar 12 15:29:13 start_ddns: update WWW.TUNNELBROKER.NET heipv6tb, wan_unit 0
Mar 12 15:29:13 ddns_update: ez-ipupdate: starting...
Mar 12 15:29:13 ddns_update: connected to ipv4.tunnelbroker.net (64.62.200.2) on port 80.
Mar 12 15:29:14 ddns_update: request successful: This tunnel is already associated with this IP address. Please try to limit your updates to IP changes.
Mar 12 15:29:14 ddns_update: asusddns_update: 0
Mar 12 15:29:14 ddns: ddns update ok
Mar 12 15:29:14 ddns_update: exit_main

Looks like inadyn and tunnelbroker do not play nice together or something in the www.tunnelbroker.net preset is wrong for at least 348.9 and maybe even 348.7 and 347.8 since I did not try those.

What do you think RMerlin? I will stay on 348.6 until you find out what is happening and if you think you have a fix I am willing to try it for you.

Inadyn works fine with Tunnelbroker, I just tested it again. You have to change your parameters, as Inadyn uses a newer API, which requires different parameters. For instance it now uses an update key instead of your password. Make sure you enter the exact parameters specified on all three input fields.

Code:
Mar 12 18:37:28 inadyn[2872]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Mar 12 18:37:28 inadyn[2872]: Checking for IP# change, connecting to checkip.dyndns.org([216.146.43.71]:80)
Mar 12 18:37:28 inadyn[2872]: Current IP# 192.xxx.yyy.zzz at default@tunnelbroker.net
Mar 12 18:37:28 inadyn[2872]: Update forced for alias 361xxx, new IP# 192.xxx.yyy.zzz
Mar 12 18:37:28 inadyn[2872]: Sending IP# update to DDNS server, connecting to ipv4.tunnelbroker.net([64.62.200.2]:443)
Mar 12 18:37:28 inadyn[2872]: Sending IP# update to DDNS server, initiating HTTPS ...
Mar 12 18:37:28 inadyn[2872]: SSL connection using ECDHE-RSA-AES256-GCM-SHA384
Mar 12 18:37:28 inadyn[2872]: SSL server cert subject: /OU=Domain Control Validated/CN=tunnelbroker.net
Mar 12 18:37:28 inadyn[2872]: SSL server cert issuer: /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
Mar 12 18:37:28 inadyn[2872]: Successful alias table update for 361xxx => new IP# 192.xxx.yyy.zzz
Mar 12 18:37:28 inadyn[2872]: Updating cache for 361xxx
 

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top