[Qemu-devel] weird slirp problems (dns lookups stopped working, and maybe more)

[Qemu-devel] weird slirp problems (dns lookups stopped working, and maybe more)

[Juergen Lock]

Hi!

 I'm not sure why I didn't notice signs of this earlier (using the
Dec 25 snapshot, I'm on FreeBSD), maybe I really only talked to the host
(10.0.2.2) from inside guests.  Anyway, after I first saw it yesterday
night, today I sniffed on the external interface and saw dns requests
of a `host google.com' going out to 224.0.0.251, port 5353, instead
of the dns in resolv.conf.  Hmm?  And when I patched slirp like this:

Index: qemu/slirp/slirp.c
@@ -130,6 +130,7 @@
 void slirp_init(void)
 {
     //    debug_init("/tmp/slirp.log", DEBUG_DEFAULT);
+        debug_init("/usr/tmp/slirp.log", DEBUG_DEFAULT);
     
 #ifdef _WIN32
     {
Index: qemu/slirp/udp.c
@@ -104,6 +104,9 @@
 	 */
 	ip = mtod(m, struct ip *);
 	uh = (struct udphdr *)((caddr_t)ip + iphlen);
+#if 1
+	DEBUG_MISC((dfd, " udp_input(), ip_dst.s_addr=0x%x, uh_dport=%d\n", ntohl(ip->ip_dst.s_addr), ntohs(uh->uh_dport)));
+#endif
 
 	/*
 	 * Make mbuf data length reflect UDP length.

 it indeed shows slirp is getting the dest ip + port correctly and
then sends them out wrong:

 ...
m_get...
 m = 9bd7800
ip_input...
 m = 9bd7800
 m_len = 56
udp_input...
 m = 9bd7800
 iphlen = 20
 udp_input(), ip_dst.s_addr=0xa000203, uh_dport=53
sosendto...
 so = 9b39b80
 m = 9bd7800
 sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
 m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
 ...

 In between I see these which I'm not sure where they are coming from:

 ...
m_get...
 m = 9bd7800
ip_input...
 m = 9bd7800
 m_len = 74
udp_input...
 m = 9bd7800
 iphlen = 20
 udp_input(), ip_dst.s_addr=0xe00000fb, uh_dport=5353
sosendto...
 so = 9b39b80
 m = 9bd7800
 sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
 m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
m_get...
 m = 9bd7000
ip_input...
 m = 9bd7000
 m_len = 74
udp_input...
 m = 9bd7000
 iphlen = 20
 udp_input(), ip_dst.s_addr=0xe00000fb, uh_dport=5353
sosendto...
 so = 9b39b80
 m = 9bd7000
 sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
 m = 9bd7800
ip_slowtimo...
tcp_slowtimo...
ip_slowtimo...
tcp_slowtimo...

 And this is my try giving the real dns (which worked yesterday btw):

m_get...
 m = 9bd7800
ip_input...
 m = 9bd7800
 m_len = 56
udp_input...
 m = 9bd7800
 iphlen = 20
 udp_input(), ip_dst.s_addr=0xd9ed958e, uh_dport=53
sosendto...
 so = 9b39b80
 m = 9bd7800
 sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
 m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
 ...

 I also got a report which stated that for him also tcp stopped working,
while I still can do http://<google.com's ip> and get the expected page,
and as said I can also ssh (and scp) to the host (10.0.2.2).

 Soo, does anyone know slirp enough to have an idea whats going on here?
The puzzling thing is I don't see recent slirp commits that could be
relevant either...

 Thanx,
	Juergen

[Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more)

[Juergen Lock]

On Tue, Jan 09, 2007 at 09:47:40PM +0100, Juergen Lock wrote:
> Hi!
> 
>  I'm not sure why I didn't notice signs of this earlier (using the
> Dec 25 snapshot, I'm on FreeBSD), maybe I really only talked to the host
> (10.0.2.2) from inside guests.  Anyway, after I first saw it yesterday
> night, today I sniffed on the external interface and saw dns requests
> of a `host google.com' going out to 224.0.0.251, port 5353, instead
> of the dns in resolv.conf.  [...]

>  In between I see these which I'm not sure where they are coming from:
> 
>  ...
> m_get...
>  m = 9bd7800
> ip_input...
>  m = 9bd7800
>  m_len = 74
> udp_input...
>  m = 9bd7800
>  iphlen = 20
>  udp_input(), ip_dst.s_addr=0xe00000fb, uh_dport=5353
> sosendto...
>  so = 9b39b80
>  m = 9bd7800
>  sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
> m_free...
>  m = 9bd7000
> ip_slowtimo...
> tcp_slowtimo...
>  ...

Ok, garrison on irc just helped solve this mystery:  This (the same)
one actually goes out first, before the 10.0.2.3 one (I didn't notice
at first), and since slirp reuses the socket because the source ip and
port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the
dest ip), the second packet with the 10.0.2.3 dest ip (which gets
replaced with the hosts's dns) goes out wrong.  And the reason this
worked previously with the same guest is multicast started working
only recently...

 (Now why tcp stopped working for the other guy I still don't know...)

 Thanx,
	Juergen

[Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more)

[Juergen Lock]

On Wed, Jan 10, 2007 at 12:04:03AM +0100, Juergen Lock wrote:
>...
> Ok, garrison on irc just helped solve this mystery:  This (the same)
> one actually goes out first, before the 10.0.2.3 one (I didn't notice
> at first), and since slirp reuses the socket because the source ip and
> port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the
> dest ip), the second packet with the 10.0.2.3 dest ip (which gets
> replaced with the hosts's dns) goes out wrong.  And the reason this
> worked previously with the same guest is multicast started working
> only recently...

And here's the fix I just added to the FreeBSD qemu port: (thanx garrison!)

Index: qemu/slirp/udp.c
@@ -205,8 +208,6 @@
 	  /* udp_last_so = so; */
 	  so->so_laddr = ip->ip_src;
 	  so->so_lport = uh->uh_sport;
-	  so->so_faddr = ip->ip_dst; /* XXX */
-	  so->so_fport = uh->uh_dport; /* XXX */
 	  
 	  if ((so->so_iptos = udp_tos(so)) == 0)
 	    so->so_iptos = ip->ip_tos;
@@ -216,6 +217,15 @@
 	   * and if it is, do the fork_exec() etc.
 	   */
 	}
+
+	/*
+	 * Assign destination unconditionally
+	 *
+	 * This fixes the case where packets are sent from the same
+	 * source ip/port to different destination ips/ports
+	 */
+	so->so_faddr = ip->ip_dst; /* XXX */
+	so->so_fport = uh->uh_dport; /* XXX */
 
 	iphlen += sizeof(struct udphdr);
 	m->m_len -= iphlen;

Re: [Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more) [PATCH]

[Jason Wessel]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

I posted a similar patch last year, but it was not accepted for some 
reason.  Making this change allows UDP nfs to work to a remote file 
server as well.

I would recommend, making one further change as included in this patch.  
It allows KGDBOE to operate on the local host or from a remote host 
because it allow the special 10.0.2.2 address to be translated.

I have included the patch in the e-mail once again.

signed-off-by: jason.wessel@windriver.com

Jason.




Juergen Lock wrote:
> On Wed, Jan 10, 2007 at 12:04:03AM +0100, Juergen Lock wrote:
>   
>> ...
>> Ok, garrison on irc just helped solve this mystery:  This (the same)
>> one actually goes out first, before the 10.0.2.3 one (I didn't notice
>> at first), and since slirp reuses the socket because the source ip and
>> port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the
>> dest ip), the second packet with the 10.0.2.3 dest ip (which gets
>> replaced with the hosts's dns) goes out wrong.  And the reason this
>> worked previously with the same guest is multicast started working
>> only recently...
>>     
>
> And here's the fix I just added to the FreeBSD qemu port: (thanx garrison!)
>
> Index: qemu/slirp/udp.c
> @@ -205,8 +208,6 @@
>  	  /* udp_last_so = so; */
>  	  so->so_laddr = ip->ip_src;
>  	  so->so_lport = uh->uh_sport;
> -	  so->so_faddr = ip->ip_dst; /* XXX */
> -	  so->so_fport = uh->uh_dport; /* XXX */
>  	  
>  	  if ((so->so_iptos = udp_tos(so)) == 0)
>  	    so->so_iptos = ip->ip_tos;
> @@ -216,6 +217,15 @@
>  	   * and if it is, do the fork_exec() etc.
>  	   */
>  	}
> +
> +	/*
> +	 * Assign destination unconditionally
> +	 *
> +	 * This fixes the case where packets are sent from the same
> +	 * source ip/port to different destination ips/ports
> +	 */
> +	so->so_faddr = ip->ip_dst; /* XXX */
> +	so->so_fport = uh->uh_dport; /* XXX */
>  
>  	iphlen += sizeof(struct udphdr);
>  	m->m_len -= iphlen;
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   


[-- Attachment #2: always_set_udp_faddr.patch --]
[-- Type: text/plain, Size: 1400 bytes --]

Index: qemu/slirp/udp.c
===================================================================
--- qemu.orig/slirp/udp.c
+++ qemu/slirp/udp.c
@@ -205,8 +205,6 @@ udp_input(m, iphlen)
 	  /* udp_last_so = so; */
 	  so->so_laddr = ip->ip_src;
 	  so->so_lport = uh->uh_sport;
-	  so->so_faddr = ip->ip_dst; /* XXX */
-	  so->so_fport = uh->uh_dport; /* XXX */
 	  
 	  if ((so->so_iptos = udp_tos(so)) == 0)
 	    so->so_iptos = ip->ip_tos;
@@ -216,6 +214,13 @@ udp_input(m, iphlen)
 	   * and if it is, do the fork_exec() etc.
 	   */
 	}
+	/* Always reset the from address as it can change,
+	 * as with NFS for example where it will talk to
+	 * the same destination port with multiple source
+	 * addresses. Or different gdb session to kgdboe.
+	 */
+	so->so_faddr = ip->ip_dst; /* XXX */
+	so->so_fport = uh->uh_dport; /* XXX */
 
 	iphlen += sizeof(struct udphdr);
 	m->m_len -= iphlen;
@@ -312,7 +317,8 @@ int udp_output(struct socket *so, struct
     struct sockaddr_in saddr, daddr;
 
     saddr = *addr;
-    if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr) {
+    if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr &&
+        addr->sin_addr.s_addr == htonl(0x7f000001)) {
         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
             saddr.sin_addr.s_addr = alias_addr.s_addr;

Re: [Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more) [PATCH]

[Igor Kovalenko]

[-- Attachment #1: Type: text/plain, Size: 4451 bytes --]

On 1/12/07, Jason Wessel <jason.wessel@windriver.com> wrote:
>
> I posted a similar patch last year, but it was not accepted for some
> reason.  Making this change allows UDP nfs to work to a remote file
> server as well.
>
> I would recommend, making one further change as included in this patch.
> It allows KGDBOE to operate on the local host or from a remote host
> because it allow the special 10.0.2.2 address to be translated.
>
> I have included the patch in the e-mail once again.
>
> signed-off-by: jason.wessel@windriver.com
>
> Jason.
>
>
>
>
> Juergen Lock wrote:
> > On Wed, Jan 10, 2007 at 12:04:03AM +0100, Juergen Lock wrote:
> >
> >> ...
> >> Ok, garrison on irc just helped solve this mystery:  This (the same)
> >> one actually goes out first, before the 10.0.2.3 one (I didn't notice
> >> at first), and since slirp reuses the socket because the source ip and
> >> port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the
> >> dest ip), the second packet with the 10.0.2.3 dest ip (which gets
> >> replaced with the hosts's dns) goes out wrong.  And the reason this
> >> worked previously with the same guest is multicast started working
> >> only recently...
> >>
> >
> > And here's the fix I just added to the FreeBSD qemu port: (thanx
> garrison!)
> >
> > Index: qemu/slirp/udp.c
> > @@ -205,8 +208,6 @@
> >         /* udp_last_so = so; */
> >         so->so_laddr = ip->ip_src;
> >         so->so_lport = uh->uh_sport;
> > -       so->so_faddr = ip->ip_dst; /* XXX */
> > -       so->so_fport = uh->uh_dport; /* XXX */
> >
> >         if ((so->so_iptos = udp_tos(so)) == 0)
> >           so->so_iptos = ip->ip_tos;
> > @@ -216,6 +217,15 @@
> >          * and if it is, do the fork_exec() etc.
> >          */
> >       }
> > +
> > +     /*
> > +      * Assign destination unconditionally
> > +      *
> > +      * This fixes the case where packets are sent from the same
> > +      * source ip/port to different destination ips/ports
> > +      */
> > +     so->so_faddr = ip->ip_dst; /* XXX */
> > +     so->so_fport = uh->uh_dport; /* XXX */
> >
> >       iphlen += sizeof(struct udphdr);
> >       m->m_len -= iphlen;
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
>
>
>
> Index: qemu/slirp/udp.c
> ===================================================================
> --- qemu.orig/slirp/udp.c
> +++ qemu/slirp/udp.c
> @@ -205,8 +205,6 @@ udp_input(m, iphlen)
>           /* udp_last_so = so; */
>           so->so_laddr = ip->ip_src;
>           so->so_lport = uh->uh_sport;
> -         so->so_faddr = ip->ip_dst; /* XXX */
> -         so->so_fport = uh->uh_dport; /* XXX */
>
>           if ((so->so_iptos = udp_tos(so)) == 0)
>             so->so_iptos = ip->ip_tos;
> @@ -216,6 +214,13 @@ udp_input(m, iphlen)
>            * and if it is, do the fork_exec() etc.
>            */
>         }
> +       /* Always reset the from address as it can change,
> +        * as with NFS for example where it will talk to
> +        * the same destination port with multiple source
> +        * addresses. Or different gdb session to kgdboe.
> +        */
> +       so->so_faddr = ip->ip_dst; /* XXX */
> +       so->so_fport = uh->uh_dport; /* XXX */
>
>         iphlen += sizeof(struct udphdr);
>         m->m_len -= iphlen;
> @@ -312,7 +317,8 @@ int udp_output(struct socket *so, struct
>      struct sockaddr_in saddr, daddr;
>
>      saddr = *addr;
> -    if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr)
> {
> +    if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr
> &&
> +        addr->sin_addr.s_addr == htonl(0x7f000001)) {
>          saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>          if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
>              saddr.sin_addr.s_addr = alias_addr.s_addr;
>
>
Indeed here it is
http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00392.html
seems like that comment there is wrong though - the patch helps setting
correct destination addr/port, not the source ones.

IMHO slirp UDP proxy bugfix is unconditionally worth committing :) but it
should be separated from host loopback address translation enhancement. It
is not clear if that would work at all in case guest is talking via UDP to
different destinations from the same source address.

-- 
Kind regards,
Igor V. Kovalenko

[-- Attachment #2: Type: text/html, Size: 7823 bytes --]