Web Server behind FritzBox

[thomas]

Don’t worry
So now the prefix is set correctly in Dynv6. Just in case you didn’t do it yet: Don’t forget to revert the update string to the version with placeholders (from Sam’s suggestion, or mine, as you like it).

Unfortunately the public IP6 address is still resolved as in your screenshot, i.e. it has not been updated as it is supposed to be.

Please verify on the Records page - there is an edit button, too - what address the Data field contains. I guess it’s the one that is returned on ping. The old prefix is still there and overrides the new one. If you shorten the address to the pure host part ::211:32ff:fe64:3fdc (Edit button) then it should work. In this case the resulting complete IPv6 address (prefix+host part) will change along with the prefix automatically each time the prefix is modified.
I’ve tried it out: Seven languages, whow!

Regarding your question: No, the display language doesn’t affect the correct setting of the variables. If the update URL is set correctly with the right placeholders, the prefix should be updated correctly, too. I believe it was properly set all the time but just not used.

[47906]

This is what I see when I click on my zones in dynv6:

This is what I see when I click on the Edit Zone from the previous screenshot:

This is what I see when I click on TAB Records, beside TAB Status from first screenshot:

This is what I see when I click on the edit button from previous screenshot:

I have clicked on the edit button from the screenshot above and put the MAC address of my Synology: ::211:32ff:fe64:3fdc.

By returning back to previous screen I still see the old whole IPv6 address:

After click on the both arrows beside Data Fieldname, I can see the MAC address:

is this an expected behavior or should I delete the record and create a new one on dynv6?

What do you mean with following expression in your last post: “I’ve tried it out: Seven languages, whow!”?

[thomas]

Hey, this looks really good now!

Yes, it’s normal that you see the whole IPv6 address. But it is not the old one any more: In your first screenshot you see 2003:dd:e71c:800:211:32ff:fe64:3fdc, now it is 2003:dd:e721:1d00:211:32ff:fe64:3fdc

BTW, the shortened address is not the MAC address (aka hardware address), but in most cases it is derived from it. A MAC address looks like 00-80-41-ae-fd-7e or 00:80:41:AE:FD:7E and belongs physically to a specific network interface. The first three bytes encode the manufacturer (off-topic here).

Your web address 47906.dynv6.net resolves correctly to 2003:dd:e721:1d00:211:32ff:fe64:3fdc now.

Seven languages: German, English, Russian, Serbian, Croatian, Macedonian, Bulgarian - got it?

If you want to test the accessibility of your synology directly via its IPv6 address, you can use the following syntax: http://[2003:dd:e721:1d00:211:32ff:fe64:3fdc]/

Conclusion: Your Dynv6 settings seem to be correct now. I assume the same for the Fritzbox, but this is still to be tested. Just renew the internet connection manually and make sure that the new IPv6 prefix of the Fritzbox is uploaded to the Dynv6 server as expected.

[47906]

Hi Thomas,
The script yesterday was successful only because I have run it manually over Internet browser, as proposed by you.
However after reconnecting the Fritzbox, the newly assigned IPv6 address to the Synology NAS was not updated over the script in Fritzbox.
Should I open a ticket by Frtizbox support?

[thomas]

Before you contact AVM support:
Please open the Fritzbox’s system log (System - Ereignisse) and tell me what it reports about DynDNS events. You should see “Die DynDNS-Aktualisierung war erfolgreich”. If not, it would be interesting whether it tells us something about the error. It may report a resolving error after successful update “Fehler bei der DNS-Auflösung” - this is harmless.

Please double-check the update URL (see Sam’s post) and the “Benutzername” (your token) in the Fritzbox.

Could you please also compare the IPv6 prefix in the Fritzbox with the one in Dynv6.
Our results from yesterday show that the Dynv6 configuration is now clean, so if the prefix is updated properly then the address of the Synology as a whole will be correct, too.

[47906]

Hi Thomas:

Here the Update- URL:
https://dynv6.com/api/update?hostname=&token=&ipv6prefix=ip6lanprefix
For some reason this edit window here does not show the text if enclosed in: <>
The “ip6lanprefix” text is enclosed in <> in the original Update-URL

Domainname: 47906.dynv6.net
Benutzername:
Kennwort: “none” ( empty pass is NOT allowed in Fritzbox)

IPv6 prefix by Fritzbox: 2003:dd:e723:b900::/56

IPv6 prefix by Dynv6:

[thomas]

Thanks, Latchezar.
What I can see: The Fritzbox does send an update request to Dynv6, which is refused. The return code 400 (bad request) points to a malformed URL string.
So what is wrong with the request?
I assume your update URL looks like this (if you are unsure, please compare):
https://dynv6.com/api/update?hostname=<domain>&token=<username>&ipv6prefix=<ip6lanprefix>
(I put a backslash in front of each opening angle bracket, like this: \< )
I can approve this is correct, as I use this URL string, too.

Your DynDNS settings in the Fritzbox:

> Domainname: 47906.dynv6.net
> Benutzername:
> Kennwort: “none” ( empty pass is NOT allowed in Fritzbox)

Here the field for “Benutzername” (user name) is empty. It must contain your Dynv6 token. Ok, you shouldn’t publish it here, but make sure it is present. When sending its update request, the Fritzbox will replace the string <username> (including the brackets) with what you filled in here.
If everything is set correctly in this tab, the URL that the Fritzbox composes and sends to Dynv6 will be exactly the same as the one you sent manually, and successfully, with the browser.

[47906]

Thank you, Thomas!
I can confirm the string is configured exactly as described by you.
Even more, the same string with replaced variable values taken from Fritzbox fields: Domainname, Benutzername and Kennwort are successfully updating the Dynv6 over Internet browser and it works from there, but not from Fritzbox string by reconnecting.

https://dynv6.com/api/update?hostname=<domain>&token=<username>&ipv6prefix=<ip6lanprefix>

In the Fritzbox configuration page I can see the English/German variables:
<domain>/<Domainname> = 47906.dynv6.net
<username>/<Benutzername> = my token without brackets, provided from the Dynv6 page
<ip6lanprefix> - I am not sure where this information is coming from, as this is not to be given manually by me on the Fritzbox configuration page

Additionally on the Fritzbox configuration page, there is a variable:
<pass>/<Kennwort> - as no empty string is allowed, I put here “none” as text without brackets

By parsing the Update-URL in an Internet-browser and replacing the variables in brackets with the given above values the Dynv6 record is correctly updated and working fine.

However, the Fritzbox script is not working by reconnecting?!?
I am going to open a support ticket by AVM (Fritzbox support)

[thomas]

Hello Latchezar,

this is really weird - and frustrating. So let’s see what AVM support says… It would be nice if you’d publish their answer here.
<ip6lanprefix> is the prefix given by the provider (Telekom). The Fritzbox knows it, so you need not set it manually. For <pass> you can set whatever you want, as Dynv6 doesn’t use it.
Is your FritzOS up to date? I believe this is one of the first questions AVM will ask. Latest version is 7.28, but it worked for me with older versions, too.

I am certain that your Fritzbox does not send the correct values in its URL string. Maybe there are blanks or other invisible special characters. Especially the domain name is a candidate for that. So perhaps it could help to type it manually into the field.

There is one last try I could offer you, if you want:
In the Update-URL string, replace dynv6.com with boerner.click and leave everything else as it is. Feel free to replace some characters in the middle of the token in the “Benutzername” field.
Then re-connect in order to generate a new update request.
This will definitely not update your DNS record, of course. Instead, the request would be sent to a dummy server under my control so I could inspect it and see what the Fritzbox actually sends. If you chose this option, it would be helpful to tell me the approx. time of the request. Don’t forget to revert the URL to its original afterwards

[47906]

Hehh, the answer from AVM is very common as I expected.
They are pointing me to they help page where is explained how initially to configure the script:

"
…vielen Dank für Ihre Anfrage an den AVM Support.
Wenn ich Sie richtig verstanden habe, nutzen Sie eine FRITZ!Box 7560 mit der FRITZ!OS-Version 7.27 an Ihrem Anschluss der Telekom.
Sie beschreiben uns, dass es zu Schwierigkeiten kommt bei der Einrichtung Ihres Dynv6.com Anbieters in der FRITZ!Box.

Ich gehe zum aktuellen Zeitpunkt davon aus, dass die Update-URL des Anbieters nicht korrekt kopiert wurde oder variablen fehlen.

In unserer Online-Hilfe zur FRITZ!Box 7560 gehen wir auf weiteren Konfigurationen ein, welche ich Ihnen empfehle zu berücksichtigen:

https://service.avm.de/help/de/FRITZ-Box-7560/019p2/hilfe_dyndns
…
"

My Fritz OS is 7.27 and looks actual:

I just changed the URL from dynv6 to boerner.click and reconected the fritzbox with the original token.
I trust you and furthermore I can anytime request a new token from the dynv6 site.

The difference I can see is that the IPv4 status shows now the same result as the IPv6:
“unbekannt” instead of “Fehler” for IPv4 status in previous tests.

[thomas]

Thank you for your confidence, Latchezar!

Unfortunately I cannot see any activity from your side on my server. It’s probably my fault: you should rather use www.boerner.click instead of simply boerner.click. Sorry for that.
So would you please retry it with that address?
It’s normal that you don’t see any positive effect on your side, as my server has nothing to to with Dynv6. The request itself will fail, but he idea is that I would see in my log what your Fritzbox was actually sending, and hopefully what’s going wrong.

[makonieczny]

Hi,
so i had the same problem as Latchezar. I d like to reach an synology nas behind a Fritzbox 6490 with Vodafone (cable) as ISP. Since its ds-lite i was glad i found dynv6.

Using
https://dynv6.com/api/update?hostname=&token=&ipv6prefix=
as update-url didn´t work as you can see below.

Online Monitor

Log

The solution was to use this link:
https://dynv6.com/api/update?hostname=&token=&ipv4= https://dynv6.com/api/update?hostname=&token=&ipv6prefix=

I dont know why it is necessary to call ipv4, but the result was

Prefix and IP were updated as expected.

[47906]

Hi, my problem was slightly different. I want to update the IPv6 address without any IPv4 address.
This is necessary for me because my Fritzbox is configured to redirect one and the same PORT 80 request to different machines in the local network, based on the IP version. Also IPv6 request on port 80 goes to my NAS WEB station and IPv4 request on port 80 goes to a Windows Desktop IIS server.
Thomas has helped very much here and proposed to change the Update-URL script as follow:

I am publishing the string as picture, otherwise it will not be present correct ( I do not know why)

generally the idea from Thomas is to cheat the Dynv6 by changing the URL for the IPv4 configuration leading into nirvana and to report only the IPv6, which works for me so far

[thomas]

Meanwhile I’ve been in contact with AVM and they are confirming IPv4 being necessary to update along with the IPv6 prefix. So if we don’t want this we need to work around it with a dummy “server” address. AVM suggested to try out another update string having the token at the end, but that didn’t work reliably.

Another thing I’d like to mention here:
While trying out several update URLs it can happen that the record changes in an unintended manner. So make sure the record contains the local part (aka host part, or interface ID) i.e. the right part of the device’s IPv6 address only, not the prefix. Otherwise an updated prefix won’t take any effect on the IPv6 address published by Dynv6. In the Record tab, click on Edit to verify.