mirror of
https://github.com/qdm12/ddns-updater.git
synced 2026-06-04 14:21:55 -04:00
Bug: IPv6 doesn't always include last 4 parts. #209
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @charlesomer on GitHub (Aug 27, 2022).
Originally assigned to: @qdm12 on GitHub.
TLDR: IPv6 address sometimes gets set without the last 4 parts.
Is this urgent: Yes
DNS provider(s) you use: Digital Ocean
Program version: Running version latest built on 2022-03-15T14:38:50Z (commit
584597d)Running version latest built on 2020-03-13T01:30:06Z (commit d0f678c)What are you using to run the container: docker-compose
Extra information (optional): I have tried with both /64 and /128. I can't see a way to exec into the container to test the curls but they work fine from the host. Apologies if I've missed something obvious. It's odd to me that it will sometimes work correctly.
Logs:
Due to restarting the container I don't have the logs at the moment.
Configuration file (remove your credentials!):
Host OS:
Raspberry Pi OS 32 bit
@edaubert commented on GitHub (Jan 11, 2023):
I had the same issue but specifying
IPV6_PREFIX=/128seems to have fix it@tom-a-wagner commented on GitHub (May 4, 2023):
I have the same issue. Setting
IPV6_PREFIX=/128explicitely doesn't help.However, I found that the issue only happens when using http as a public ip fetcher, while I get the correct ip when using dns, but then another error.
I manually specified a single site so I can query it manually to compare, it returned (redacted)
aaaa:bbbb:cccc:dddd::d89.The http method however just determines
aaaa:bbbb:cccc:dddd::as my address:When using dns instead, this happens:
The IP is determined and updated correctly, but then i get
mismatching IP address received: aaaa:bbbb:cccc:dddd::with the incorrect IP, not sure what that error means.@qdm12 commented on GitHub (Jun 12, 2023):
Please pull the latest image and try again. A lot of work has been going on recently to use
net/netipip addresses and some changes were made regarding the masking for ipv6, so maybe it will help. Error messages should now be clearer too regarding the mismatching IP address received thing.For google, it happens in the code here:
936bf4386e/internal/settings/providers/google/provider.go (L166)So the ip you get from the response is different from the ip sent out to update your record with, most likely due to that ipv6 prefix mask I guess?
@tom-a-wagner commented on GitHub (Jun 12, 2023):
Just tested again with commit
5676673.No change, except that setting
PUBLICIP_FETCHERS=dnsnow results in the same output as settinghttp.The address is still printed with the last part missing:
@qdm12 commented on GitHub (Jun 12, 2023):
Fixed in
81b336fe07and6513e5869amy bad that was a regression introduced with the "Environment variables parsing was changed on 12 June, please report any issue you might have"What do you get with:
These two urls are for IPv6 only by HTTP. Maybe it's just their response which is wrong 🤔
And also out of curiosity (this one is for ipv4 or ipv6), what do you get from:
? Thanks!! 👍
@qdm12 commented on GitHub (Jun 12, 2023):
EDIT: fixing that bad commit 1 minute
Solved it for http: 21be712d845228f2d62790d0429474058548e1a8
TLDR: used a bad regex from a ihateregex.com which really makes me hate regex and this website.
@Ryuukyu313 can you create an issue with the logs running the latest ddns image to see why it complains about a mismatching ip address (
When using dns instead, this happens:) thank you!@qdm12 commented on GitHub (Jun 12, 2023):
I will finish fixing it tomorrow (it's 11pm here 💤), but yeah the ipv6 regex is bad, and I can't find a decent one (and don't want to do a phd on regex either), so I'm writing my own ipv6 extraction function which will be more reliable and tested.
@qdm12 commented on GitHub (Jun 13, 2023):
Fixed in
954dffd3a7@tom-a-wagner commented on GitHub (Jun 13, 2023):
@qdm12 Can confirm
954dffd3a7fixes the issue, the correct IP address is now updated.The mismatch error when using the dns fetcher is also no longer present, it works just fine now.
Looking at the old logs again, I'd suspect that the same faulty regex was used on the response from googledomains,
which then caused the mismatch.
And thanks a lot for your work! Out of all ddns clients I've tried, yours is now the only one I could get to work with my IPv6-only setup.