Dumbpipe Listen not working on windows 11 #17
Comments
|
Hi @sundayglee, a DEBUG log would be very helpful to be able to see what is going on. Unfortunately it doesn't seem like you attached it. Could you still give us the debug log? |
|
@flub Here are the logs; the last timeout logs repeats constantly: |
|
It looks like iroh can't do any DNS lookups, initially attempts result in:
After a while they turn into:
The result of this is that we can't connect to any derp servers and thus can never connect to anything. Do you know of any reason why your machine might not be allowing the use of DNS to iroh? |
|
For what it's worth, iroh ships with it's own DNS resolver and does not use the system one. So it needs to bind a UDP socket and make the request to a server itself. |
|
I did change my DNS server to 8.8.8.8, now the DNS resolution is working but still the issue is persisting. Here are the new logs: |
|
Thanks for the new logs! From what I understand you may be on a dual-stack machine, so it has both IPv4 and IPv6 interfaces, but only IPv4 is routable. This is an entirely normal configuration, probably the most common in the world. So nothing wrong there, just checking I understand correctly what is going on. However the primary problem appears to be with the system configuration for the DNS resolvers, or at least with how our DNS resolver uses that configuration. It seems to strongly prefer doing DNS lookups to the Now something then goes wrong and things indeed get stuck as you can see in the final messages just repeating. This last bug might be solved in the current main branch of iroh. I would be keen to see if that would works at least eventually with your However why the system tells the resolver to first try the IPv6 DNS servers I don't know. This is also something we should try and understand. I'm not familiar with windows myself so if you could try and investigate what is going on with the system DNS configuration that would be much appreciated. |
|
Over at n0-computer/iroh#2069 I'm debugging the same DNS server issue on one of our CI machines. So far it seems I can see them when running |
3 tasks
|
Ok, I think n0-computer/iroh#2075 is the most sensible fix for this. I think you could locally fix this immediately by removing the IPv6 loopback interface on your machine and then those phantom DNS servers would probably disappear. Though I wouldn't mind if you could build from that PR and confirm that it works correctly on your system using it :) |
github-merge-queue bot
pushed a commit
to n0-computer/iroh
that referenced
this issue
Mar 13, 2024
## Description This actively refuses to use the `fec0:0:0:ffff::1`, `fec0:0:0:ffff::2` and `fec0:0:0:ffff::3` DNS servers if the system has them configured. Windows by default adds 3 IPv6 site-local anycast addresses to the DNS servers: `fec0:0:0:ffff::1`, `fec0:0:0:ffff::2` and `fec0:0:0:ffff::3`. Supposedly Microsoft DNS servers by default listen on those. These are present as soon as there's an IPv6 interface configured it seems, even for a loopback interface which is extremely common if not the default. Our hickory-resolver loads the system configuration, which includes these 3 IPv6 DNS servers. When it needs to make a DNS query it selects a random nameserver and tries this. If that fails it will try another one. For the next query there is bias, it will remember which servers to avoid or use. So if you get lucky and your first query falls on an actual DNS server then you are good. If you get unlucky recovering is a bit of a tussle because: Inside netcheck we do DNS queries with a 1s timeout, this because all the probes have a 3s timeout. However hickory-resolver has a 5s timeout configured, so it's queries stay alive longer than ours. This means almost all subsequent DNS queries will end up reusing an existing connection to one of those bad servers if you are unlucky to land on one. The interplay of these timeouts and the connection reuse make recovering to a good DNS server a rather tough prospect for netcheck. It probably would eventually, given enough netcheck runs (which run at intervals of ~30s). The odds of these nameservers being the sole way of having working DNS is basically zero. The odds of these nameservers breaking the resolver are about 50%. So remove these deprecated things. ## Notes & open questions Unfortunately the resolver returned by `get_resolver()` does not have an API that allows to test it. But the test would basically be the inverse logic of the logic that removes the bad servers so perhaps not that useful anyway. Closes #2069 Closes n0-computer/dumbpipe#17 ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant.
|
@flub At last i got it to work but it was a try and error and don't know exactly why this is happening. After you suggested for me to disable IPv6 protocol, i did try to do that in the interface connected to the internet. But strangely, Maybe someone in here, has a knowledge of what is happening. |
Yes, this was also my observation. I believe once you're running code with n0-computer/iroh#2075 in it you should no longer have the mess with disabling your IPv6 interfaces. |
rklaehn
pushed a commit
to n0-computer/iroh-blobs
that referenced
this issue
Oct 22, 2024
## Description This actively refuses to use the `fec0:0:0:ffff::1`, `fec0:0:0:ffff::2` and `fec0:0:0:ffff::3` DNS servers if the system has them configured. Windows by default adds 3 IPv6 site-local anycast addresses to the DNS servers: `fec0:0:0:ffff::1`, `fec0:0:0:ffff::2` and `fec0:0:0:ffff::3`. Supposedly Microsoft DNS servers by default listen on those. These are present as soon as there's an IPv6 interface configured it seems, even for a loopback interface which is extremely common if not the default. Our hickory-resolver loads the system configuration, which includes these 3 IPv6 DNS servers. When it needs to make a DNS query it selects a random nameserver and tries this. If that fails it will try another one. For the next query there is bias, it will remember which servers to avoid or use. So if you get lucky and your first query falls on an actual DNS server then you are good. If you get unlucky recovering is a bit of a tussle because: Inside netcheck we do DNS queries with a 1s timeout, this because all the probes have a 3s timeout. However hickory-resolver has a 5s timeout configured, so it's queries stay alive longer than ours. This means almost all subsequent DNS queries will end up reusing an existing connection to one of those bad servers if you are unlucky to land on one. The interplay of these timeouts and the connection reuse make recovering to a good DNS server a rather tough prospect for netcheck. It probably would eventually, given enough netcheck runs (which run at intervals of ~30s). The odds of these nameservers being the sole way of having working DNS is basically zero. The odds of these nameservers breaking the resolver are about 50%. So remove these deprecated things. ## Notes & open questions Unfortunately the resolver returned by `get_resolver()` does not have an API that allows to test it. But the test would basically be the inverse logic of the logic that removes the bad servers so perhaps not that useful anyway. Closes #2069 Closes n0-computer/dumbpipe#17 ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi n0 team,
I am trying to use
dumbpipe listenin Windows 11 but i get the following errors which repeats constantly:I enabled DEBUG logging by setting
RUST_LOG=DEBUGand got the attached log dump.When using Ubungu WSL environment, Dumbpipe works fine.
I have tried to check the windows firewall to see if any port is blocked or the connections are blocked, but they are normal and no blocking occurs.
Can anyone help me to get dumbpipe to work in Windows 11?
Uploading log.txt…
The text was updated successfully, but these errors were encountered: