DNS resolver woes #17
Comments
That IP address points to Which kind of problems are you having with DNS resolution? We would need to diagnose them first to be able to look for a solution. |
Yeah, I realized that after looking around. It works for me anyway.
@aqrln Could you share what's in your @dylanchapell is somehow left only with the search domain inside the VM... Probably a |
Sorry I didn't have a chance to check yet (I needed to be on macOS since the beginning of the week), I saw your response to me in the gist as well. I'll get back to you asap next time I boot into Linux. |
|
I'm also not sure if the problem was with DNS in my case, if I remember correctly, I also tried pinging some IPs from within the VM and that didn't work either (although I could reach them from the host). |
|
@aqrln ping currently doesn't work, that's as expected |
|
Ah, okay, good to know! Regarding my |
|
This is my |
|
@RossComputerGuy Please also share |
|
Cannot due to #19 preventing me from running anything. |
|
@teohhanhui apologies for the delay, here's my and inside the krun VM: There are also the following warnings in |
|
An detail that stands out looking at @RossComputerGuy's |
|
With this hack: diff --git a/crates/krun-guest/src/net.rs b/crates/krun-guest/src/net.rs
index 3710bd5..27e4d37 100644
--- a/crates/krun-guest/src/net.rs
+++ b/crates/krun-guest/src/net.rs
@@ -1,4 +1,4 @@
-use std::{fs, os::unix::process::ExitStatusExt, process::Command};
+use std::{fs, io::Write, os::unix::process::ExitStatusExt, process::Command};
use anyhow::{anyhow, Context, Result};
use log::debug;
@@ -35,5 +35,10 @@ pub fn configure_network() -> Result<()> {
Err(err)?;
}
+ fs::File::options()
+ .append(true)
+ .open("/etc/resolv.conf")?
+ .write_all("nameserver 1.1.1.1\n".as_bytes())?;
+
Ok(())
}DNS works inside the VM: |
|
I also tried hardcoding |
|
@aqrln |
|
Did some digging...
The error comes from I don't really understand why it fails to do the |
@aqrln 's hack worked for me. I also use tailscale. |
Minor correction to this statement: passt doesn't actually implement a DNS server, not even a relay or a responder: it will just do NAT for UDP packets to/from port 53 if it sees a loopback address configured as resolver on the host (or if explicitly configured with
Weird, that's unexpected. Can you have a look at which command line options (say, from |
|
This is working with I think we can close this? |
We recently fixed a few issues with UDP forwarding, possibly affecting DNS responses as well. that might have caused this, even though I'm not sure exactly which fix applies here. Anyway, glad to hear it now works for you, and thanks for re-testing with the latest version! |
|
@teohhanhui @sbrivio-rh thank you both! |
|
@sbrivio-rh I regret to inform that the a recent passt update in Fedora 40 (probably EDIT: Actually this seems like a different issue. I just realized I don't have |
|
|
|
Doesn't seem to be a DNS issue... There's no connectivity from within the krun VM. |
Ouch, strange, that one shouldn't have any related change. Do you remember what the "good" version was?
Not really, look:
Here it gives up and picks an IPv4 link-local (196.254.0.0/16) as fallback, which you see here:
But it should be the same as the host, 192.168.1.105/24. For some reason, it's not getting any address via DHCP. I'll try to reproduce this (not right now, but soon). I don't need Asahi, right? I guess I can just use krun on Fedora 40 x86_64? |
I need to actually try a downgrade (wonder if that might break many things lol),
Yes. |
|
Tried with https://bodhi.fedoraproject.org/updates/FEDORA-2024-4632bfa865 - it's also broken. So I don't think it's |
|
Well, not elegant, but I just commented out most the matching part in I'll try on Fedora 40 next. If you want to help debugging this, you could pass some options to |
|
That looks fine, even though there are no connections shown. Any luck with the traffic capture ( |
|
The pcap is attached in the gist, and it's only 24 bytes... So it's just... empty? 😆
Seems like nothing is reaching passt then... The pcap file stays at 24 bytes no matter what I do. |
Oops, I didn't even notice... yes, that's just the header, no packets.
Right. I wonder if it's something with SELinux. Could you try running this in permissive mode? I haven't checked with Fedora 40 yet but I think I'll do it tomorrow. |
Just tried. No change. |
|
I wish I could help but I did want to pipe in and say I'm having this issue as well. I have no idea how all this works but I did try to compile using the first version of crates/krun-guest/src/net.rs that exists in this repo by going back to the first commit, using that file and applying the patch, and then compiling. No dice. I'm aware that this probably isn't too helpful because I have no clue what I'm doing but I did just want to show what I have done. Thought process was maybe it would work with dhclient.
|
|
Hah, I reproduced it on Fedora 40, with |
|
It works, also on Fedora 40, if I start passt separately: and then make |
|
@teohhanhui at this point, I would like to trace reads and writes to |
|
You can use something like: (change And add the |
|
Without adding any additional print, I happened to reproduce this, just once, also on Fedora rawhide, with this output: On Fedora 40, instead, it's like this: I guess Fedora rawhide comes with By the way, Anyway, I looked a bit into the code, but I can't quite understand where reads and writes onto this file descriptor are. I guess they're implemented in libkrun instead... but I would have no idea how to get output from libkrun onto a standard stream, or even just how to change libkrun and then make krun use the new version with changes. So I'm afraid I can't very productively help with this. Let me know if there's anything I can debug on passt side, though. |
Probably here: https://github.com/containers/libkrun/blob/main/src/devices/src/virtio/net/passt.rs When you build
Something like: |
|
Thanks for the pointers. Despite being thick I'm quite confident I could eventually grasp how it all works one day, given enough time... which I don't have, though. ;) Just one thing occurred to me with your latest command line: Why is the file descriptor 6, then 4? |
From your log, while |
|
...and they are two endpoints of a connected socket pair, I guess? |
|
Yes. |
|
I was confused by the fact that usually Linux gives back contiguous numbers (even though sure, it might be that |
|
Okay, this is weird: PID 9573 is passt. |
|
I think krun fails to actually drop SOCK_CLOEXEC before running passt: For passt, 6 is now a TCP socket, because the old "6" was closed on exec. There's no explicit close between socket() and execve(). |
|
Ouch, no: So I introduced some issue in https://passt.top/passt/commit/?id=09603cab28f9883baf1d7b48bdc102d6641dc300, I guess. |
|
And I've just realized why my previous downgrade of |
|
On the other hand ...so we're closing |
|
Fix (in passt): I'll submit it for review in a bit. The problem is that if there are non-option arguments (including values for other options) before |
I forgot: |
|
The fix is included in passt version 2024_08_21.1d6142f, and its matching Fedora 40 update. |
…pen_files() Seen with krun: we get a file descriptor via --fd, but we close it and happily use the same number for TCP files. The issue is that if we also get other options before --fd, with arguments, getopt_long() stops parsing them because it sees them as non-option values. Use the - modifier at the beginning of optstring (before :, which is needed to avoid printing errors) instead of +, which means we'll continue parsing after finding unrelated option values, but getopt_long() won't reorder them anyway: they'll be passed with option value '1', which we can ignore. By the way, we also need to add : after F in the optstring, so that we're able to parse the option when given as short name as well. Now that we change the parsing mode between close_open_files() and conf(), we need to reset optind to 0, not to 1, whenever we call getopt_long() again in conf(), so that the internal initialisation of getopt_long() evaluating GNU extensions is re-triggered. Link: https://github.com/slp/krun/issues/17#issuecomment-2294943828 Fixes: baccfb9 ("conf: Stop parsing options at first non-option argument") Fixes: 09603ca ("passt, util: Close any open file that the parent might have leaked") Signed-off-by: Stefano Brivio <[email protected]> Reviewed-by: David Gibson <[email protected]>
In the VM, my
/etc/resolv.conflooks like this:Which is bad, because that's my router's IP address... (And not what's sent as DNS servers via DHCP.)
Others have reported no Internet access in the VM, probably related to this.
If I understand correctly, I think that's why
krunvmsetnameserver 1.1.1.1as the default:https://github.com/containers/krunvm/blob/5494d84a66bee3b802a0392cf8d662158ac7287d/src/main.rs#L51
But that's also not a good solution as it'd break local domains and search domains among other things...
The text was updated successfully, but these errors were encountered: