mirror of
https://github.com/mageddo/dns-proxy-server.git
synced 2026-04-25 17:35:54 +03:00
[GH-ISSUE #427] DPS is spamming me with exception: java.lang.RuntimeException: Array of bytes is not a valid IP representation: fddb:21e4:36d4:1::1/64: invalid IPv6 address #150
Labels
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/dns-proxy-server-mageddo#150
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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 @pschiffe on GitHub (Nov 22, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/427
What is Happening / What is expected
I have IPv4 & IPv6 enabled VM. DPS is spamming me with this exception all the time:
java.lang.RuntimeException: Array of bytes is not a valid IP representation: fddb:21e4:36d4:1::1/64: invalid IPv6 addressThis IP is visible in the
ip aoutput:Other than the spamming, DPS seems to work:
Specs
3.15.13-snapshot-aarch64@pschiffe commented on GitHub (Nov 22, 2023):
MG_LOG_LEVEL: ERRORenv var seems to "resolve" this@mageddo commented on GitHub (May 2, 2024):
I've no idea why it's happening, it's a very weird scenario for me. Looks like your network Gateway IP is set to
fddb:21e4:36d4:1::1/64instead offddb:21e4:36d4:1::1,/64it's supposed to be set at t he Subnet, not at the Gateway IP.The behavior is related to that snippet of code
github.com/mageddo/dns-proxy-server@bdb1eb00e7/src/main/java/com/mageddo/dnsproxyserver/docker/DockerNetworkService.java (L38-L39)Please, check your network configs by running
My example bellow (I wasn´t allowed to create the network with an invalid gateway IP, but don't know, maybe it was possible in past versions of docker).
@pschiffe commented on GitHub (May 2, 2024):
The IPv6 gateway and subnet is automatically assigned by Docker in my case, I've just configured the pools in the Docker config:
@mageddo commented on GitHub (May 2, 2024):
Your network inspect looks fine, I doesn't explain the execution error.
If you are still getting the the issue, please change the log level to TRACE, simulate the scenario and attach the logs.
Then execute the command bellow with the network id of the network logged at
status=bestNetwork, network=$NETWORK_NAME, ip=right before the exception and attach the result.@pschiffe commented on GitHub (May 3, 2024):
Hm, I've upgraded to 3.16.3 and set log level to INFO, but it seems that I'm not getting these errors anymore. I also did a bit of rework of the dns proxy setup since I started with it, so that could be related as well.
I'm sorry, I don't have anything else for you. Feel free to close this issue and I'll reopen if it starts again.
@mageddo commented on GitHub (May 3, 2024):
No problem, happy the issue is fixed for now, thanks for your patience.
@pschiffe commented on GitHub (Jun 17, 2024):
Hello @mageddo, I'm still seeing this issue. Usually after the container is created, it's not possible to resolve it. Tried with the latest DPS version
3.19.5. When looking at the docker network inspect, there's is this weird address :("Gateway": "fddb:21e4:36d4:9::1/64". Other networks don't have the/64in gateway, not sure when it disappears :/@pschiffe commented on GitHub (Jun 17, 2024):
Restarting docker daemon fixes this:
@pschiffe commented on GitHub (Jun 17, 2024):
After the docker daemon restart, resolution with DPS works OK.
@mageddo commented on GitHub (Jun 17, 2024):
It really looks like an unwanted behavior from docker, but I wasn't able to find a issue on docker repo related to it. Can you upgrade your docker version to check if it fixes your issue?
If wouldn't fix that issue, then I can work on a workaround at DPS IP mapping to remove the
'/64'at the end.@pschiffe commented on GitHub (Jun 18, 2024):
The OS is fully updated Fedora 39, Docker is provided by
moby-engine-24.0.5-1.fc39.aarch64package, which is an upstream for Docker. I use ansible to manage the containers, so there's also the latestcommunity.docker 3.10.4ansible collection and on the managed host, the python librarypython3-docker-6.1.3-1.fc39.noarch. I guess the issue can be anywhere here.The
moby-engineon Fedora is supposed to be better integrated with the OS, but they have some issues with upgrading to the newer version, so it's still in the works.Currently I'm not able to reasonably update anything further. I don't have Fedora 40 yet on the servers, but the moby-engine version is the same.
@mageddo commented on GitHub (Jun 18, 2024):
No problem, I Will generate a patch with the hotfix
@pschiffe commented on GitHub (Jun 19, 2024):
Hi @mageddo. I've just tested this on a Rocky 9 with the latest Docker CE package:
And the behavior is the same:
@mageddo commented on GitHub (Jun 21, 2024):
3.19.7-snapshot binaries will be release at the next minutes @pschiffe , please can you give me a feedback if it fixes your usecase?
@pschiffe commented on GitHub (Jun 22, 2024):
I can confirm it works now! Thank you so much 🥇
@mageddo commented on GitHub (Jun 22, 2024):
Glad issue it's now fixed, thanks for your donation :)