From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Lu=EDs?= Silva <luis.silva@axiomasoft.pt>
Subject: Re: [Xen-devel] ARP problems with xen 4.0 with pvops
	kernel
Date: Wed, 02 Jun 2010 09:47:31 +0100
Message-ID: <1275468451.2999.17.camel@luis-port>
References: <1275439138.2202.27.camel@luis-port> <4C05B1D8.4000104@goop.org>
Reply-To: luis.silva@axiomasoft.pt
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0764987463=="
Return-path: <xen-users-bounces@lists.xensource.com>
In-Reply-To: <4C05B1D8.4000104@goop.org>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>,
	<mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-users@lists.xensource.com>
List-Help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>,
	<mailto:xen-users-request@lists.xensource.com?subject=subscribe>
Sender: xen-users-bounces@lists.xensource.com
Errors-To: xen-users-bounces@lists.xensource.com
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org


--===============0764987463==
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-nJMXT8BMfz2c3+08vzwn"


--=-nJMXT8BMfz2c3+08vzwn
Content-Type: multipart/alternative; boundary="=-kjyiNrVRMqOqc5476vxT"


--=-kjyiNrVRMqOqc5476vxT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

I'm using the latest stable-2.6.32.x. I already tried "ethtool -K
<bridge> tx off", but that didn't make any difference. Also, this only
happen with pv, in hvm mode all works ok and the domU sees the arp
messages...

Thanks,
Lu=C3=ADs

On Tue, 2010-06-01 at 18:20 -0700, Jeremy Fitzhardinge wrote:

> On 06/01/2010 05:38 PM, Lu=C3=ADs Silva wrote:
> > Hello,
> >
> > Finally I managed to get a xen 4.0 working on ubuntu 10.04 with pvops
> > kernel and libvirt. However I am having some problems with
> > networking... after initial installation with netinstall image in hvm
> > mode, when I transform the vm in xen pv (via pygrub with the current
> > ubuntu kernel), networking startEd to act weird...
> >
> > Basically I'm not using a network script from xen. I define a bridge
> > (manually or via libvirt, the result is the same) and I use vif-bridge
> > to connect the vif to it. But now the weird part comes: I can
> > communicate from domU to dom0, but not the other way around, unless I
> > keep a ping running from domU to dom0... That's right, weird... while
> > trying the ping from dom0 to domU, I used tcpdump both on the bridge,
> > on the vif and on the eth0 in the domU. The arp packets never get to
> > domU, but they appear both in the bridge and the vif sniff's...
>=20
> What version of kernel are you using in dom0 and domU?  There was a
> netback bug which caused problems with dom0<->domU communication, but it
> has been fixed for a while in 2.6.32 (but only recently in .31).  The
> workaround is to disable tx checksum offload on your bridge (ethtool -K
> <bridge> tx off).
>=20
>     J
>=20
> >
> > Here is the bridge:
> > ifconfig virbr0
> > virbr0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff =20
> >           inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.25=
5.255.0
> >           inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:Link
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:226 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:0=20
> >           RX bytes:952 (952.0 B)  TX bytes:13953 (13.9 KB)
> >
> >
> > brctl show
> > bridge name	bridge id		STP enabled	interfaces
> > virbr0		8000.feffffffffff	no		vif5.0
> >
> >
> > tcpdump -i virbr0 -vv -n
> > tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture size=
 96 bytes
> > 01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 1=
, length 64
> > 01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 2=
, length 64
> > 01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 3=
, length 64
> > 01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 4=
, length 64
> > 01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 5=
, length 64
> > 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 6=
, length 64
> > 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 7=
, length 64
> > 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto =
ICMP (1), length 84)
> >     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 8=
, length 64
> > 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> >
> >
> > tcpdump -i vif5.0 -vv -n
> > tcpdump: WARNING: vif5.0: no IPv4 address assigned
> > tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), capture size=
 96 bytes
> > 01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> > 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 19=
2.168.120.1 tell 192.168.120.254, length 28
> >  =20
> >
> >
> > Forwarding and iptables don't seem to be the problem, because if I
> > initiate a ping from domU (at the same time as the failing one from
> > dom0), the ping in dom0 starts to work. As soon as I stop the ping in
> > domU, the one in dom0 starts failing again...
> >
> > Is anyone having the same problem? Is this a bug in the kernel? In
> > dom0 or domU?
> >
> > Thanks in advance,
> > Lu=C3=ADs
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >  =20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>=20



--=-kjyiNrVRMqOqc5476vxT
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.28.3">
</HEAD>
<BODY>
Hello,<BR>
<BR>
I'm using the latest stable-2.6.32.x. I already tried &quot;ethtool -K &lt;=
bridge&gt; tx off&quot;, but that didn't make any difference. Also, this on=
ly happen with pv, in hvm mode all works ok and the domU sees the arp messa=
ges...<BR>
<BR>
Thanks,<BR>
Lu&#237;s<BR>
<BR>
On Tue, 2010-06-01 at 18:20 -0700, Jeremy Fitzhardinge wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
On 06/01/2010 05:38 PM, Lu&#237;s Silva wrote:
&gt; Hello,
&gt;
&gt; Finally I managed to get a xen 4.0 working on ubuntu 10.04 with pvops
&gt; kernel and libvirt. However I am having some problems with
&gt; networking... after initial installation with netinstall image in hvm
&gt; mode, when I transform the vm in xen pv (via pygrub with the current
&gt; ubuntu kernel), networking startEd to act weird...
&gt;
&gt; Basically I'm not using a network script from xen. I define a bridge
&gt; (manually or via libvirt, the result is the same) and I use vif-bridge
&gt; to connect the vif to it. But now the weird part comes: I can
&gt; communicate from domU to dom0, but not the other way around, unless I
&gt; keep a ping running from domU to dom0... That's right, weird... while
&gt; trying the ping from dom0 to domU, I used tcpdump both on the bridge,
&gt; on the vif and on the eth0 in the domU. The arp packets never get to
&gt; domU, but they appear both in the bridge and the vif sniff's...

What version of kernel are you using in dom0 and domU?  There was a
netback bug which caused problems with dom0&lt;-&gt;domU communication, but=
 it
has been fixed for a while in 2.6.32 (but only recently in .31).  The
workaround is to disable tx checksum offload on your bridge (ethtool -K
&lt;bridge&gt; tx off).

    J

&gt;
&gt; Here is the bridge:
&gt; ifconfig virbr0
&gt; virbr0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff =20
&gt;           inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.2=
55.255.0
&gt;           inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:Link
&gt;           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
&gt;           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
&gt;           TX packets:226 errors:0 dropped:0 overruns:0 carrier:0
&gt;           collisions:0 txqueuelen:0=20
&gt;           RX bytes:952 (952.0 B)  TX bytes:13953 (13.9 KB)
&gt;
&gt;
&gt; brctl show
&gt; bridge name	bridge id		STP enabled	interfaces
&gt; virbr0		8000.feffffffffff	no		vif5.0
&gt;
&gt;
&gt; tcpdump -i virbr0 -vv -n
&gt; tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture siz=
e 96 bytes
&gt; 01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 1, length 64
&gt; 01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 2, length 64
&gt; 01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 3, length 64
&gt; 01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 4, length 64
&gt; 01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 5, length 64
&gt; 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 6, length 64
&gt; 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 7, length 64
&gt; 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto=
 ICMP (1), length 84)
&gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, s=
eq 8, length 64
&gt; 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt;
&gt;
&gt; tcpdump -i vif5.0 -vv -n
&gt; tcpdump: WARNING: vif5.0: no IPv4 address assigned
&gt; tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), capture siz=
e 96 bytes
&gt; 01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt; 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1=
92.168.120.1 tell 192.168.120.254, length 28
&gt;  =20
&gt;
&gt;
&gt; Forwarding and iptables don't seem to be the problem, because if I
&gt; initiate a ping from domU (at the same time as the failing one from
&gt; dom0), the ping in dom0 starts to work. As soon as I stop the ping in
&gt; domU, the one in dom0 starts failing again...
&gt;
&gt; Is anyone having the same problem? Is this a bug in the kernel? In
&gt; dom0 or domU?
&gt;
&gt; Thanks in advance,
&gt; Lu&#237;s
&gt;
&gt;
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <A HREF=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</A>
&gt; <A HREF=3D"http://lists.xensource.com/xen-devel">http://lists.xensourc=
e.com/xen-devel</A>
&gt;  =20


_______________________________________________
Xen-devel mailing list
<A HREF=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</A>
<A HREF=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.com=
/xen-devel</A>

</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>

--=-kjyiNrVRMqOqc5476vxT--

--=-nJMXT8BMfz2c3+08vzwn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAkwGGpgACgkQXSU0BM8MHj9Z8QCdHIyHrIJU9cgytN2YY8mTcTia
nvEAn3mIAZa5MtyHNwybCVRubk+u9Xrh
=+ULS
-----END PGP SIGNATURE-----

--=-nJMXT8BMfz2c3+08vzwn--



--===============0764987463==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
--===============0764987463==--