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-users] Re: ARP problems with xen 4.0 with
	pvops kernel
Date: Thu, 03 Jun 2010 11:20:24 +0100
Message-ID: <1275560425.23424.4.camel@luis-port>
References: <83243.28786.qm@web56103.mail.re3.yahoo.com>
Reply-To: luis.silva@axiomasoft.pt
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0519353283=="
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <83243.28786.qm@web56103.mail.re3.yahoo.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Boris Derzhavets <bderzhavets@yahoo.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, xen-users@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org


--===============0519353283==
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-rJhcdfACVkZwAf0tom/i"


--=-rJhcdfACVkZwAf0tom/i
Content-Type: multipart/alternative; boundary="=-n4R76bgoXVwPDtZUQR9/"


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

Hello,

Thanks for the suggestion, xen/stable works ok for me. Only problem is
that I have to disable offload do get dhcp to work on domU, but the
problem I described before doesn't exist in this kernel. Later today I'm
going to try a previous build I have based on stable-2.6.32.x
(2.6.32.13) to check if it already had this problem or not and I'll post
the results.

Lu=C3=ADs

On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:

> Could you,please, build and try 2.6.32.10 ( xen/stable) ?
>=20
> Boris.
>=20
> --- On Wed, 6/2/10, Lu=C3=ADs Silva <luis.silva@axiomasoft.pt> wrote:
>=20
>        =20
>         From: Lu=C3=ADs Silva <luis.silva@axiomasoft.pt>
>         Subject: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0
>         with pvops kernel
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: xen-devel@lists.xensource.com,
>         xen-users@lists.xensource.com
>         Date: Wednesday, June 2, 2010, 2:53 PM
>        =20
>        =20
>         Hello,
>        =20
>         On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote:=20
>        =20
>         > On 06/02/2010 01:47 AM, Lu=C3=ADs Silva wrote:
>         > > Hello,
>         > >
>         > > I'm using the latest stable-2.6.32.x. I already tried "ethtoo=
l -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 th=
e arp
>         > > messages...
>         >=20
>         > Yes, ARP is a new twist on network problems.  I'm guessing you'=
re using
>         > hvm without stubdoms, which means that its networking originate=
s from
>         > qemu within dom0, whereas PV and HVM+stubdom comes via netback.
>         >=20
>        =20
>         Yes, when I mentioned hvm I was talking about hvm without
>         stubdoms. I haven't tried those yet.=20
>        =20
>         > But aside from that, I'm stumped.  Are you running any firewall=
s on
>         > either side?   Can you try disabling all the offloads (tx, rx, =
gso, tso)
>         > on all the relevent interfaces (bridge, netback, within the gue=
st) and
>         > see if that changes anything?
>         >=20
>         >     J
>         >=20
>        =20
>        =20
>         Ok, this is the bridge interface:
>        =20
>        =20
>         brctl show
>         bridge name	bridge id		STP enabled	interfaces
>         virbr0		8000.feffffffffff	no		vif1.0
>        =20
>         ifconfig virbr0
>         virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23 =20
>                   inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:=
255.255.255.0
>                   inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
>                   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>                   TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
>                   collisions:0 txqueuelen:0=20
>                   RX bytes:0 (0.0 B)=20
>          TX bytes:4662 (4.6 KB)
>        =20
>        =20
>         I'm not using firewall other than the rules defined by
>         libvirt. DomU has no firewall and the rules in dom0 are only
>         these (virbr0 is natted to the outside, virbr1 is routed. The
>         result is the same in either one of them):=20
>        =20
>         sudo iptables -L -n -v
>         Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
>          pkts bytes target     prot opt in     out     source            =
   destination        =20
>             0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0         =
   0.0.0.0/0           udp dpt:53=20
>             0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0         =
   0.0.0.0/0           tcp dpt:53
>         =20
>             0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0         =
   0.0.0.0/0           udp dpt:67=20
>             0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0         =
   0.0.0.0/0           tcp dpt:67=20
>             8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0         =
   0.0.0.0/0           udp dpt:53=20
>             0     0
>          ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/=
0           tcp dpt:53=20
>             0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0         =
   0.0.0.0/0           udp dpt:67=20
>             0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0         =
   0.0.0.0/0           tcp dpt:67=20
>        =20
>         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>          pkts bytes target     prot
>          opt in     out     source               destination        =20
>             0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0         =
   192.168.121.0/24   =20
>             0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24  =
   0.0.0.0/0          =20
>             0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0         =
 =20
>          0.0.0.0/0          =20
>             0     0 REJECT     all  --  *      virbr1  0.0.0.0/0         =
   0.0.0.0/0           reject-with icmp-port-unreachable=20
>             0     0 REJECT     all  --  virbr1 *       0.0.0.0/0         =
   0.0.0.0/0           reject-with icmp-port-unreachable=20
>            13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0         =
   192.168.120.0/24    state
>          RELATED,ESTABLISHED=20
>            16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24  =
   0.0.0.0/0          =20
>             0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0         =
   0.0.0.0/0          =20
>             0     0 REJECT     all  --  *      virbr0  0.0.0.0/0         =
   0.0.0.0/0           reject-with icmp-port-unreachable=20
>             0     0 REJECT     all  --  virbr0
>          *       0.0.0.0/0            0.0.0.0/0           reject-with icm=
p-port-unreachable=20
>        =20
>         Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
>          pkts bytes target     prot opt in     out     source            =
   destination
>        =20
>        =20
>        =20
>         And these are the various offload parameters as set at boot:
>        =20
>        =20
>         Offload parameters for virbr0:
>         rx-checksumming: on
>         tx-checksumming: on
>         scatter-gather: on
>         tcp-segmentation-offload: on
>         udp-fragmentation-offload: on
>         generic-segmentation-offload: on
>         generic-receive-offload: off
>         large-receive-offload: off
>        =20
>         Offload parameters for vif1.0:
>         rx-checksumming: on
>         tx-checksumming: on
>         scatter-gather: on
>         tcp-segmentation-offload: on
>         udp-fragmentation-offload: off
>         generic-segmentation-offload: on
>         generic-receive-offload: off
>         large-receive-offload: off
>        =20
>         Offload parameters for eth0:
>         rx-checksumming: on
>         tx-checksumming: on
>         scatter-gather: on
>         tcp-segmentation-offload: on
>         udp-fragmentation-offload: off
>         generic-segmentation-offload: off
>         generic-receive-offload: off
>         large-receive-offload: off
>        =20
>        =20
>         To disable all checksuming I run the following commands:
>         dom0:=20
>        =20
>         sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
>         sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off
>        =20
>         domU=20
>        =20
>         sudo ethtool -K eth0 tx off sg off tso off gso off gro off
>        =20
>        =20
>         This managed to get all parameter to off in the mentioned
>         interfaces, but unfortunately the result is the same. The arp
>         requests get to vif1.0, but not to eth0 on the domU.
>        =20
>        =20
>         sudo tcpdump -i vif1.0 -n -vv arp
>         tcpdump: WARNING: vif1.0: no IPv4 address assigned
>         tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), captur=
e size 96 bytes
>         19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-=
has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request who-=
has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request who-=
has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-=
has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request who-=
has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request who-=
has 192.168.120.1 tell 192.168.120.254, length 28
>        =20
>        =20
>         I hope this information is enough. If I can provide anything
>         else to help debug or test, please just ask! ;)
>        =20
>         Thanks in advance,
>         Lu=C3=ADs
>        =20
>        =20
>         > >
>         > > 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 i=
mage in hvm
>         > >> > mode, when I transform the vm in xen pv (via pygrub with t=
he current
>         > >> > ubuntu kernel), networking startEd to act weird...
>         > >> >
>         > >> > Basically I'm not using a network script from xen. I defin=
e a bridge
>         > >> > (manually or via libvirt, the result is the same) and I us=
e 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 aroun=
d,
>         >  unless I
>         > >> > keep a ping running from domU to dom0... That's right, wei=
rd... 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 ne=
ver get to
>         > >> > domU, but they appear both in the bridge and the vif sniff=
's...
>         > >>
>         > >> What version of kernel are you using in dom0 and domU?  Ther=
e was a
>         > >> netback bug which caused problems with dom0<->domU communica=
tion, 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).
>         > >>
>         > >>     J
>         > >>
>         > >> >
>         > >> > Here is the bridge:
>         > >> > ifconfig virbr0
>         > >> > virbr0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff =20
>         > >> >         =20
>         >  inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255=
.255.0
>         > >> >           inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:L=
ink
>         > >> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric=
:1
>         > >> >           RX packets:16 errors:0 dropped:0 overruns:0 fram=
e:0
>         > >> >           TX packets:226 errors:0 dropped:0 overruns:0 car=
rier: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), Reque=
st who-has 192.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), Reque=
st who-has 192.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), Reque=
st who-has 192.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)
>         > >> >   =20
>         >  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), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has
>         >  192.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), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> >
>         >  01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request w=
ho-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> > 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Reque=
st who-has 192.168.120.1 tell 192.168.120.254, length 28
>         > >> >  =20
>         > >> >
>         > >> >
>         > >> > Forwarding and iptables don't seem to be the problem, beca=
use 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 <mailto:Xen-devel@lists.xens=
ource.com>
>         > >> > http://lists.xensource.com/xen-devel
>         > >> >  =20
>         > >>
>         > >>
>         > >> _______________________________________________
>         > >> Xen-devel mailing list
>         > >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensou=
rce.com>
>         > >> http://lists.xensource.com/xen-devel
>         > >>
>         > >>    =20
>         > >
>         >=20
>         >=20
>        =20
>        =20
>        =20
>        =20
>        =20
>         -----Inline Attachment Follows-----
>        =20
>        =20
>         _______________________________________________
>         Xen-users mailing list
>         Xen-users@lists.xensource.com
>         http://lists.xensource.com/xen-users
>=20



--=-n4R76bgoXVwPDtZUQR9/
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>
Thanks for the suggestion, xen/stable works ok for me. Only problem is that=
 I have to disable offload do get dhcp to work on domU, but the problem I d=
escribed before doesn't exist in this kernel. Later today I'm going to try =
a previous build I have based on stable-2.6.32.x (2.6.32.13) to check if it=
 already had this problem or not and I'll post the results.<BR>
<BR>
Lu&#237;s<BR>
<BR>
On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:<BR>
<BLOCKQUOTE TYPE=3DCITE>
    <TABLE CELLSPACING=3D"0" CELLPADDING=3D"0">
<TR>
<TD VALIGN=3D"top">
Could you,please, build and try 2.6.32.10 ( xen/stable) ?<BR>
<BR>
Boris.<BR>
<BR>
--- On <B>Wed, 6/2/10, Lu&#237;s Silva </B><B><I>&lt;luis.silva@axiomasoft.=
pt&gt;</I></B> wrote:<BR>
<BLOCKQUOTE>
    <BR>
    From: Lu&#237;s Silva &lt;luis.silva@axiomasoft.pt&gt;<BR>
    Subject: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvo=
ps kernel<BR>
    To: &quot;Jeremy Fitzhardinge&quot; &lt;jeremy@goop.org&gt;<BR>
    Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com<BR>
    Date: Wednesday, June 2, 2010, 2:53 PM<BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE>
    Hello,<BR>
    <BR>
    On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote:=20
    <BLOCKQUOTE TYPE=3DCITE>
<PRE>
On 06/02/2010 01:47 AM, Lu&#237;s Silva wrote:
&gt; Hello,
&gt;
&gt; I'm using the latest stable-2.6.32.x. I already tried &quot;ethtool -K
&gt; &lt;bridge&gt; tx off&quot;, but that didn't make any difference. Also=
, this only
&gt; happen with pv, in hvm mode all works ok and the domU sees the arp
&gt; messages...

Yes, ARP is a new twist on network problems.  I'm guessing you're using
hvm without stubdoms, which means that its networking originates from
qemu within dom0, whereas PV and HVM+stubdom comes via netback.

</PRE>
    </BLOCKQUOTE>
    Yes, when I mentioned hvm I was talking about hvm without stubdoms. I h=
aven't tried those yet.=20
    <BLOCKQUOTE TYPE=3DCITE>
<PRE>
But aside from that, I'm stumped.  Are you running any firewalls on
either side?   Can you try disabling all the offloads (tx, rx, gso, tso)
on all the relevent interfaces (bridge, netback, within the guest) and
see if that changes anything?

    J

</PRE>
    </BLOCKQUOTE>
    <BR>
    Ok, this is the bridge interface:<BR>
    <BR>
<PRE>
brctl show
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.feffffffffff	no		vif1.0

ifconfig virbr0
virbr0&nbsp;&nbsp;&nbsp; Link encap:Ethernet&nbsp; HWaddr c2:ef:67:2b:a4:23=
&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inet addr:192.168.12=
0.254&nbsp; Bcast:192.168.120.255&nbsp; Mask:255.255.255.0
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inet6 addr: fe80::c0=
ef:67ff:fe2b:a423/64 Scope:Link
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UP BROADCAST RUNNING=
 MULTICAST&nbsp; MTU:1500&nbsp; Metric:1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RX packets:0 errors:=
0 dropped:0 overruns:0 frame:0
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TX packets:25 errors=
:0 dropped:0 overruns:0 carrier:0
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; collisions:0 txqueue=
len:0=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RX bytes:0 (0.0 B)&n=
bsp;
 TX bytes:4662 (4.6 KB)
</PRE>
    <BR>
    I'm not using firewall other than the rules defined by libvirt. DomU ha=
s no firewall and the rules in dom0 are only these (virbr0 is natted to the=
 outside, virbr1 is routed. The result is the same in either one of them):=20
<PRE>
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
 pkts bytes target&nbsp;&nbsp;&nbsp;&nbsp; prot opt in&nbsp;&nbsp;&nbsp;&nb=
sp; out&nbsp;&nbsp;&nbsp;&nbsp; source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; destination&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; udp&nbsp; --&nbsp; virbr1 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; udp dpt:53=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; tcp&nbsp; --&nbsp; virbr1 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tcp dpt:53
=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; udp&nbsp; --&nbsp; virbr1 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; udp dpt:67=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; tcp&nbsp; --&nbsp; virbr1 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tcp dpt:67=20
&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp; 515 ACCEPT&nbsp;&nbsp;&nbsp;&nbsp; udp&nbs=
p; --&nbsp; virbr0 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; udp dpt:53=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0
 ACCEPT&nbsp;&nbsp;&nbsp;&nbsp; tcp&nbsp; --&nbsp; virbr0 *&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; tcp dpt:53=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; udp&nbsp; --&nbsp; virbr0 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; udp dpt:67=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; tcp&nbsp; --&nbsp; virbr0 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tcp dpt:67=20

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target&nbsp;&nbsp;&nbsp;&nbsp; prot
 opt in&nbsp;&nbsp;&nbsp;&nbsp; out&nbsp;&nbsp;&nbsp;&nbsp; source&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; virbr1&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168=
.121.0/24&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; virbr1 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.=
121.0/24&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; virbr1 virbr1&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 REJECT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; virbr1&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reject-with =
icmp-port-unreachable=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 REJECT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; virbr1 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reject-with =
icmp-port-unreachable=20
&nbsp;&nbsp; 13&nbsp; 3448 ACCEPT&nbsp;&nbsp;&nbsp;&nbsp; all&nbsp; --&nbsp=
; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; virbr0&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.120.0/24&nbsp;&nbsp=
;&nbsp; state
 RELATED,ESTABLISHED=20
&nbsp;&nbsp; 16&nbsp; 1374 ACCEPT&nbsp;&nbsp;&nbsp;&nbsp; all&nbsp; --&nbsp=
; virbr0 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.120.0/24&nbsp;&nbsp;=
&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 ACCEPT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; virbr0 virbr0&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 REJECT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; virbr0&nbsp; 0.0.0.0/=
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0=
/0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reject-with =
icmp-port-unreachable=20
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0 REJECT&nbsp;&nbsp;&nbsp;&nbs=
p; all&nbsp; --&nbsp; virbr0
 *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reject-with icmp-port-unreachable=20

Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
 pkts bytes target&nbsp;&nbsp;&nbsp;&nbsp; prot opt in&nbsp;&nbsp;&nbsp;&nb=
sp; out&nbsp;&nbsp;&nbsp;&nbsp; source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; destination
</PRE>
    <BR>
    <BR>
    And these are the various offload parameters as set at boot:<BR>
    <BR>
<PRE>
Offload parameters for virbr0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for vif1.0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
</PRE>
    <BR>
    To disable all checksuming I run the following commands:<BR>
    dom0:=20
<PRE>
sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off
</PRE>
    domU=20
<PRE>
sudo ethtool -K eth0 tx off sg off tso off gso off gro off
</PRE>
    <BR>
    This managed to get all parameter to off in the mentioned interfaces, b=
ut unfortunately the result is the same. The arp requests get to vif1.0, bu=
t not to eth0 on the domU.<BR>
    <BR>
<PRE>
sudo tcpdump -i vif1.0 -n -vv arp
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 =
bytes
19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
</PRE>
    <BR>
    I hope this information is enough. If I can provide anything else to he=
lp debug or test, please just ask! ;)<BR>
    <BR>
    Thanks in advance,<BR>
    Lu&#237;s<BR>
    <BR>
    <BLOCKQUOTE TYPE=3DCITE>
<PRE>
&gt;
&gt; Thanks,
&gt; Lu&#237;s
&gt;
&gt; On Tue, 2010-06-01 at 18:20 -0700, Jeremy Fitzhardinge wrote:
&gt;&gt; On 06/01/2010 05:38 PM, Lu&#237;s Silva wrote:
&gt;&gt; &gt; Hello,
&gt;&gt; &gt;
&gt;&gt; &gt; Finally I managed to get a xen 4.0 working on ubuntu 10.04 wi=
th pvops
&gt;&gt; &gt; kernel and libvirt. However I am having some problems with
&gt;&gt; &gt; networking... after initial installation with netinstall imag=
e in hvm
&gt;&gt; &gt; mode, when I transform the vm in xen pv (via pygrub with the =
current
&gt;&gt; &gt; ubuntu kernel), networking startEd to act weird...
&gt;&gt; &gt;
&gt;&gt; &gt; Basically I'm not using a network script from xen. I define a=
 bridge
&gt;&gt; &gt; (manually or via libvirt, the result is the same) and I use v=
if-bridge
&gt;&gt; &gt; to connect the vif to it. But now the weird part comes: I can
&gt;&gt; &gt; communicate from domU to dom0, but not the other way around,
 unless I
&gt;&gt; &gt; keep a ping running from domU to dom0... That's right, weird.=
.. while
&gt;&gt; &gt; trying the ping from dom0 to domU, I used tcpdump both on the=
 bridge,
&gt;&gt; &gt; on the vif and on the eth0 in the domU. The arp packets never=
 get to
&gt;&gt; &gt; domU, but they appear both in the bridge and the vif sniff's.=
..
&gt;&gt;
&gt;&gt; What version of kernel are you using in dom0 and domU?  There was =
a
&gt;&gt; netback bug which caused problems with dom0&lt;-&gt;domU communica=
tion, but it
&gt;&gt; has been fixed for a while in 2.6.32 (but only recently in .31).  =
The
&gt;&gt; workaround is to disable tx checksum offload on your bridge (ethto=
ol -K
&gt;&gt; &lt;bridge&gt; tx off).
&gt;&gt;
&gt;&gt;     J
&gt;&gt;
&gt;&gt; &gt;
&gt;&gt; &gt; Here is the bridge:
&gt;&gt; &gt; ifconfig virbr0
&gt;&gt; &gt; virbr0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff =20
&gt;&gt; &gt;         =20
 inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.0
&gt;&gt; &gt;           inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:Link
&gt;&gt; &gt;           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
&gt;&gt; &gt;           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
&gt;&gt; &gt;           TX packets:226 errors:0 dropped:0 overruns:0 carrie=
r:0
&gt;&gt; &gt;           collisions:0 txqueuelen:0=20
&gt;&gt; &gt;           RX bytes:952 (952.0 B)  TX bytes:13953 (13.9 KB)
&gt;&gt; &gt;
&gt;&gt; &gt;
&gt;&gt; &gt; brctl show
&gt;&gt; &gt; bridge name	bridge id		STP enabled	interfaces
&gt;&gt; &gt; virbr0		8000.feffffffffff	no		vif5.0
&gt;&gt; &gt;
&gt;&gt; &gt;
&gt;&gt; &gt; tcpdump -i virbr0 -vv -n
&gt;&gt; &gt; tcpdump: listening on virbr0, link-type EN10MB (Ethernet), ca=
pture size 96 bytes
&gt;&gt; &gt; 01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1),
 length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 1, length 64
&gt;&gt; &gt; 01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 2, length 64
&gt;&gt; &gt; 01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 3, length 64
&gt;&gt; &gt; 01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 4, length 64
&gt;&gt; &gt; 01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 5, length
 64
&gt;&gt; &gt; 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 6, length 64
&gt;&gt; &gt; 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;     192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id=
 10317, seq 7, length 64
&gt;&gt; &gt; 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [D=
F], proto ICMP (1), length 84)
&gt;&gt; &gt;   =20
 192.168.120.254 &gt; 192.168.120.1: ICMP echo request, id 10317, seq 8, le=
ngth 64
&gt;&gt; &gt; 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has
 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt;
&gt;&gt; &gt;
&gt;&gt; &gt; tcpdump -i vif5.0 -vv -n
&gt;&gt; &gt; tcpdump: WARNING: vif5.0: no IPv4 address assigned
&gt;&gt; &gt; tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), ca=
pture size 96 bytes
&gt;&gt; &gt; 01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt;
 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.1=
68.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt; 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request =
who-has 192.168.120.1 tell 192.168.120.254, length 28
&gt;&gt; &gt;  =20
&gt;&gt; &gt;
&gt;&gt; &gt;
&gt;&gt; &gt; Forwarding and iptables don't seem to be the problem, because=
 if I
&gt;&gt; &gt; initiate a ping from domU (at the same time as the failing on=
e from
&gt;&gt; &gt; dom0), the ping in dom0 starts to work. As soon as I stop the=
 ping in
&gt;&gt; &gt; domU, the one in dom0 starts failing again...
&gt;&gt; &gt;
&gt;&gt; &gt; Is anyone having the same problem? Is this a bug
 in the kernel? In
&gt;&gt; &gt; dom0 or domU?
&gt;&gt; &gt;
&gt;&gt; &gt; Thanks in advance,
&gt;&gt; &gt; Lu&#237;s
&gt;&gt; &gt;
&gt;&gt; &gt;
&gt;&gt; &gt; _______________________________________________
&gt;&gt; &gt; Xen-devel mailing list
&gt;&gt; &gt; <A HREF=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@li=
sts.xensource.com</A> &lt;<A HREF=3D"mailto:Xen-devel@lists.xensource.com">=
mailto:Xen-devel@lists.xensource.com</A>&gt;
&gt;&gt; &gt; <A HREF=3D"http://lists.xensource.com/xen-devel">http://lists=
.xensource.com/xen-devel</A>
&gt;&gt; &gt;  =20
&gt;&gt;
&gt;&gt;
&gt;&gt; _______________________________________________
&gt;&gt; Xen-devel mailing list
&gt;&gt; <A HREF=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.x=
ensource.com</A> &lt;<A HREF=3D"mailto:Xen-devel@lists.xensource.com">mailt=
o:Xen-devel@lists.xensource.com</A>&gt;
&gt;&gt; <A HREF=3D"http://lists.xensource.com/xen-devel">http://lists.xens=
ource.com/xen-devel</A>
&gt;&gt;
&gt;&gt;    =20
&gt;


</PRE>
    </BLOCKQUOTE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE>
    <BR>
    -----Inline Attachment Follows-----<BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE>
    _______________________________________________<BR>
    Xen-users mailing list<BR>
    <A HREF=3D"/mc/compose?to=3DXen-users@lists.xensource.com">Xen-users@li=
sts.xensource.com</A><BR>
    <A HREF=3D"http://lists.xensource.com/xen-users">http://lists.xensource=
.com/xen-users</A>
</BLOCKQUOTE>
</TD>
</TR>
</TABLE>
    <BR>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>

--=-n4R76bgoXVwPDtZUQR9/--

--=-rJhcdfACVkZwAf0tom/i
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)

iEYEABECAAYFAkwHgeQACgkQXSU0BM8MHj99OACcCe2JLuHm8cCdxXysywfl5ZKk
E9QAmQElNefKY4tFVNHIero7l7H++ITA
=66iZ
-----END PGP SIGNATURE-----

--=-rJhcdfACVkZwAf0tom/i--



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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0519353283==--