diff mbox

dns server not working in QEMU using usermode networking (SLIRP)

Message ID 20170505231433.ggp34jmzx4fad6jp@var.youpi.perso.aquilenet.fr
State New
Headers show

Commit Message

Samuel Thibault May 5, 2017, 11:14 p.m. UTC
FONNEMANN Mark, on ven. 05 mai 2017 22:38:20 +0000, wrote:
> >Could you run tcpdump inside the guest so we are sure what the nslookup call emits?
> 
> Is there another way to determine this info? My guest OS is an embedded system with BusyBox 1.25 and not much else.

The attached patch should be dumping the same kind of information.

Samuel

Comments

FONNEMANN Mark May 6, 2017, 12:33 a.m. UTC | #1
>The attached patch should be dumping the same kind of information.

Nslookup does not produce any output in curses or in logfile (-D logfile.txt). I tried it using the version installed on the root system (Busybox 1.0):

root@qemu:~# nslookup
                    BusyBox v1.00 (2010.04.14-20:01+0000) multi-call binary

                    Usage: nslookup [HOST] [SERVER]
root@qemu:~# nslookup www.google.com
                    *** Unknown host

                    nslookup: www.google.com: Unknown host

 as well as the newer version installed in initrd image which is version 1.25.1:

root@qemu:~# /initrd/bin/nslookup
                    BusyBox v1.25.1 (2017-05-01 19:00:24 EDT) multi-call binary.

                    Usage: nslookup [HOST] [SERVER]

                    Query the nameserver for the IP address of the given HOST
                    optionally using a specified DNS server
root@qemu:~# /initrd/bin/nslookup www.google.com
                    Server:    10.0.2.3
                    Address 1: 10.0.2.3

                    nslookup: can't resolve 'www.google.com'

I know the patch was applied because when I ping 10.0.2.2 I get the following:

root@qemu:~# ping 10.0.2.2
                    PING 10.0.2.2 (10.0.2.2): 56 data bytes
                    64 bytes from 10.0.2.2: icmp_seq=0 ttl=255 time=0.5 ms
                    64 bytes from 10.0.2.2: icmp_seq=1 ttl=255 time=0.1 ms
                    64 bytes from 10.0.2.2: icmp_seq=2 ttl=255 time=0.1 ms
                    64 bytes from 10.0.2.2: icmp_seq=3 ttl=255 time=0.1 ms
                    64 bytes from 10.0.2.2: icmp_seq=4 ttl=255 time=0.2 ms

                    --- 10.0.2.2 ping statistics ---
                    5 packets transmitted, 5 packets received, 0% packet loss
                    round-trip min/avg/max = 0.1/0.2/0.5 ms

[mfonnemann@localhost qemu]$ cat logfile
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1

mark.
Samuel Thibault May 6, 2017, 12:56 a.m. UTC | #2
FONNEMANN Mark, on sam. 06 mai 2017 00:33:40 +0000, wrote:
> >The attached patch should be dumping the same kind of information.
> 
> Nslookup does not produce any output in curses or in logfile (-D logfile.txt).

Uh.  So qemu can't be the culprit since it doesn't receive anything :)

> root@qemu:~# /initrd/bin/nslookup www.google.com
>                     Server:    10.0.2.3
>                     Address 1: 10.0.2.3
> 
>                     nslookup: can't resolve 'www.google.com'

So it's supposed to be using 10.0.2.3 I guess. Just to make sure, you
could try

/initrd/bin/nslookup www.google.com 10.0.2.3

> I know the patch was applied because when I ping 10.0.2.2 I get the following:
> 
> root@qemu:~# ping 10.0.2.2
>                     PING 10.0.2.2 (10.0.2.2): 56 data bytes
>                     64 bytes from 10.0.2.2: icmp_seq=0 ttl=255 time=0.5 ms
> [mfonnemann@localhost qemu]$ cat logfile
> ip input a00020f -> a000202 1
> ip input a00020f -> a000202 1

Do you get output when pinging 10.0.2.3?
(you won't get ping answers, but that's fine, qemu should still be able
to see the requests coming in)

Also, just to make sure: you don't have firewalling rules, do you?

Samuel
FONNEMANN Mark May 6, 2017, 1:06 a.m. UTC | #3
>So it's supposed to be using 10.0.2.3 I guess. Just to make sure, you could try
>/initrd/bin/nslookup www.google.com 10.0.2.3

root@qemu:~# /initrd/bin/nslookup www.google.com 10.0.2.3
                    Server:    10.0.2.3
                    Address 1: 10.0.2.3

                    nslookup: can't resolve 'www.google.com'

>Do you get output when pinging 10.0.2.3?
>(you won't get ping answers, but that's fine, qemu should still be able to see the requests coming in)

root@qemu:~# ping 10.0.2.3
                    PING 10.0.2.3 (10.0.2.3): 56 data bytes

                    --- 10.0.2.3 ping statistics ---
                    9 packets transmitted, 0 packets received, 100% packet loss

[mfonnemann@localhost qemu]$ cat logfile
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1

>Also, just to make sure: you don't have firewalling rules, do you?

How can I verify this? (iptables is not installed on this guest Linux)
Samuel Thibault May 6, 2017, 1:17 a.m. UTC | #4
FONNEMANN Mark, on sam. 06 mai 2017 01:06:31 +0000, wrote:
> root@qemu:~# /initrd/bin/nslookup www.google.com 10.0.2.3
>                     Server:    10.0.2.3
>                     Address 1: 10.0.2.3
> 
>                     nslookup: can't resolve 'www.google.com'

That's so weird there's no packet log. Does your guest perhaps have the
strace tool? Or perhaps you can manage to copy it over from another VM,
since it only depends on libc.

> >Do you get output when pinging 10.0.2.3?
> >(you won't get ping answers, but that's fine, qemu should still be able to see the requests coming in)
> 
> root@qemu:~# ping 10.0.2.3
>                     PING 10.0.2.3 (10.0.2.3): 56 data bytes
> 
>                     --- 10.0.2.3 ping statistics ---
>                     9 packets transmitted, 0 packets received, 100% packet loss
> 
> [mfonnemann@localhost qemu]$ cat logfile
> ip input a00020f -> a000203 1

Ok, so at least something gets through, even if not UDP 53.

Samuel
Samuel Thibault May 6, 2017, 9:23 a.m. UTC | #5
FONNEMANN Mark, on sam. 06 mai 2017 04:18:52 +0000, wrote:
> >That's so weird there's no packet log. Does your guest perhaps have the strace tool? Or perhaps you >can manage to copy it over from another VM, since it only depends on libc.
> 
> See attached file.

Ok, so for some reason it doesn't even try to emit a packet...

> open("/etc/resolv.conf", O_RDONLY)      = 3
> read(3, "nameserver 10.0.2.3\n\n", 4096) = 21

It does get the proper nameserver.

> connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)

It tries to connect to nscd but that's not running.

> open("/etc/nsswitch.conf", O_RDONLY)    = 3
> read(3, "hosts:      files\n", 4096)    = 18
> read(3, "", 4096)                       = 0

And I guess that's the culprit: in nsswitch.conf you only have
"hosts: files", so

> open("/lib/libnss_files.so.2", O_RDONLY) = 3
> open("/etc/hosts", O_RDONLY)            = 3
> read(3, "127.0.0.1\tlocalhost\n10.0.2.15\tqe"..., 4096) = 35

It only uses /etc/hosts.


So, in your /etc/nsswitch.conf, use

hosts: files dns

Samuel
FONNEMANN Mark May 6, 2017, 3:06 p.m. UTC | #6
>So, in your /etc/nsswitch.conf, use
>hosts: files dns

This resolved the problem. I am now able to do DNS queries using nslookup.
Thanks for all your help!

Mark.
diff mbox

Patch

diff --git a/slirp/ip_input.c b/slirp/ip_input.c
index 348e1dca5a..ada6f0d059 100644
--- a/slirp/ip_input.c
+++ b/slirp/ip_input.c
@@ -41,6 +41,7 @@ 
 #include "qemu/osdep.h"
 #include "slirp.h"
 #include "ip_icmp.h"
+#include "qemu/log.h"
 
 static struct ip *ip_reass(Slirp *slirp, struct ip *ip, struct ipq *fp);
 static void ip_freef(Slirp *slirp, struct ipq *fp);
@@ -93,6 +94,8 @@  ip_input(struct mbuf *m)
 
 	ip = mtod(m, struct ip *);
 
+        qemu_log("ip input %x -> %x %x\n", ntohl(ip->ip_src.s_addr), ntohl(ip->ip_dst.s_addr), ip->ip_p);
+
 	if (ip->ip_v != IPVERSION) {
 		goto bad;
 	}
diff --git a/slirp/udp.c b/slirp/udp.c
index 227d779022..521c3a5a57 100644
--- a/slirp/udp.c
+++ b/slirp/udp.c
@@ -41,6 +41,7 @@ 
 #include "qemu/osdep.h"
 #include "slirp.h"
 #include "ip_icmp.h"
+#include "qemu/log.h"
 
 static uint8_t udp_tos(struct socket *so);
 
@@ -95,6 +96,7 @@  udp_input(register struct mbuf *m, int iphlen)
 	ip = mtod(m, struct ip *);
 	uh = (struct udphdr *)((caddr_t)ip + iphlen);
 
+        qemu_log("udp input %u -> %u\n", (unsigned) ntohs(uh->uh_sport), (unsigned) ntohs(uh->uh_dport));
 	/*
 	 * Make mbuf data length reflect UDP length.
 	 * If not enough data to reflect UDP length, drop.