From: "Luís Silva" <luis.silva@axiomasoft.pt>
To: Boris Derzhavets <bderzhavets@yahoo.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-users] Re: ARP problems with xen 4.0 with pvops kernel
Date: Fri, 04 Jun 2010 00:18:21 +0100 [thread overview]
Message-ID: <1275607101.2138.24.camel@luis-port> (raw)
In-Reply-To: <841075.13411.qm@web56103.mail.re3.yahoo.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 30865 bytes --]
Hello again,
So, As I said, I had a build of 2.6.32.13 built from xen/stable-2.6.32.x
hanging around (last commit in git log is
"4dd582f35f28707a039111be9fdb8101fecb07de") and I tested it for the
particular problem I reported. The tests didn't show the problem I had,
so it should have been introduced somewhere in between...
To sumarize my findings:
* xen/stable (2.6.32.10): OK: It still has the UDP checksum
problem, but other than that, networking seems to work ok.
* xen(stable-2.6.32.x (up to commit
"4dd582f35f28707a039111be9fdb8101fecb07de"): OK: I didn't test
the checksum problem, but it should have it also as the fix was
commited after this date. My problem also doesn't show up here.
* xen/stable-2.6.32.x (2.6.32.14): NOT OK: No communication from
dom0 to domU, unless domU is generating traffic. ARP requests
from dom0 don't reach domU. As to whether the UDP checksum is
fixed or not... It should be fixed but my ubuntu 10.04 domU
still can't get a DHCP lease without disabling checksum offload
on the vif interface. At least, the UDP checksum errors don't
get to dmesg, but it still seems to be something wrong with this
kernel version. Bellow I post the tcpdump's for a DHCP request
from domU, first with default settings and the second with
offload disabled (by sudo ethtool -K vif2.0 tx off sg off tso
off gso off gro off)
This dump is *with* checksum:
sudo tcpdump -i vif2.0 -n -vv
tcpdump: WARNING: vif2.0: no IPv4 address assigned
tcpdump: listening on vif2.0, link-type EN10MB (Ethernet), capture size 96 bytes
00:04:39.314038 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0x1882cf2d, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:39.413071 IP (tos 0x0, ttl 64, id 49739, offset 0, flags [none], proto UDP (17), length 328)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300, xid 0x1882cf2d, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:44.315876 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0x1882cf2d, secs 5, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:44.316316 IP (tos 0x0, ttl 64, id 49740, offset 0, flags [none], proto UDP (17), length 328)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300, xid 0x1882cf2d, secs 5, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:49.315733 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:04:50.315687 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:04:51.315737 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:04:57.324111 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0x1882cf2d, secs 18, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:57.324498 IP (tos 0x0, ttl 64, id 49741, offset 0, flags [none], proto UDP (17), length 328)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300, xid 0x1882cf2d, secs 18, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:05:02.323734 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:05:03.323731 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:05:04.323732 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
This dump is *without* checksum:
00:05:56.313304 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0xfccb9d73, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:05:56.313902 IP (tos 0x0, ttl 64, id 49742, offset 0, flags [none], proto UDP (17), length 328)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300, xid 0xfccb9d73, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:01.313723 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:06:02.313725 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:06:03.313724 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:06:04.320745 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:04.321119 IP (tos 0x0, ttl 64, id 49743, offset 0, flags [none], proto UDP (17), length 328)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:04.325804 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:04.422863 IP (tos 0x0, ttl 64, id 49744, offset 0, flags [none], proto UDP (17), length 336)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 308, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:07.315456 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:47:57:87, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:07.440054 IP (tos 0x0, ttl 64, id 49745, offset 0, flags [none], proto UDP (17), length 336)
192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 308, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
Your-IP 192.168.120.114
Server-IP 192.168.120.254
Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:12.439828 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:06:13.439746 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
00:06:14.439674 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.114 tell 192.168.120.254, length 28
I hope this extra information can help to trace the problems.
Luís
On Thu, 2010-06-03 at 03:59 -0700, Boris Derzhavets wrote:
> > stable-2.6.32.x (2.6.32.13) to check if it already had this problem.
>
> I would guess it's OK now ;)
>
> # git branch -D xen/stable-2.6.32.x
> # git checkout -b xen/stable-2.6.32.x origin/xen/stable-2.6.32.x
> # git pull
> # make menuconfig ( will show 2.6.32.14 at the moment)
> # make
>
> >have to disable offload do get dhcp to work on domU
>
> Run tcpdump on any other box on the LAN different from Dom0 hosting.
> DHCPDISCOVER is a broadcast request, so you should be able to capture
> wrong UDP checksums. Otherwise it's gonna be a miracle.
>
> Boris.
>
>
> --- On Thu, 6/3/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:
>
>
> From: Luís Silva <luis.silva@axiomasoft.pt>
> Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen
> 4.0 with pvops kernel
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
> xen-devel@lists.xensource.com, xen-users@lists.xensource.com
> Date: Thursday, June 3, 2010, 6:20 AM
>
>
> 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ís
>
> On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:
>
> > Could you,please, build and try 2.6.32.10 ( xen/stable) ?
> >
> > Boris.
> >
> > --- On Wed, 6/2/10, Luís Silva <luis.silva@axiomasoft.pt>
> > wrote:
> >
> >
> > From: Luís 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
> >
> > Hello,
> >
> > On Wed, 2010-06-02 at 09:06 -0700, Jeremy
> > Fitzhardinge wrote:
> >
> > > On 06/02/2010 01:47 AM, Luís Silva wrote:
> > > > 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...
> > >
> > > 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.
> > >
> >
> > Yes, when I mentioned hvm I was talking about hvm
> > without stubdoms. I haven't tried those yet.
> >
> > > 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
> > >
> >
> >
> > Ok, this is the bridge interface:
> >
> >
> > brctl show
> > bridge name bridge id STP enabled interfaces
> > virbr0 8000.feffffffffff no vif1.0
> >
> > ifconfig virbr0
> > virbr0 Link encap:Ethernet HWaddr c2:ef:67:2b:a4:23
> > 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
> > RX bytes:0 (0.0
> > B)
> > TX bytes:4662 (4.6 KB)
> >
> >
> > 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):
> >
> > sudo iptables -L -n -v
> > Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
> > pkts bytes target prot opt in out source destination
> > 0 0 ACCEPT udp -- virbr1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
> > 0 0 ACCEPT tcp -- virbr1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
> >
> >
> > 0 0 ACCEPT udp -- virbr1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
> > 0 0 ACCEPT tcp -- virbr1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
> > 8 515 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
> > 0 0
> >
> > ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
> > 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
> > 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
> >
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target
> > prot
> > opt in out source destination
> > 0 0 ACCEPT all -- * virbr1 0.0.0.0/0 192.168.121.0/24
> > 0 0 ACCEPT all -- virbr1 * 192.168.121.0/24 0.0.0.0/0
> > 0 0 ACCEPT all -- virbr1 virbr1 0.0.0.0/0
> >
> > 0.0.0.0/0
> > 0 0 REJECT all -- * virbr1 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
> > 0 0 REJECT all -- virbr1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
> > 13 3448 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.120.0/24
> > state
> > RELATED,ESTABLISHED
> > 16 1374 ACCEPT all -- virbr0 * 192.168.120.0/24 0.0.0.0/0
> > 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
> > 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
> > 0 0 REJECT all --
> > virbr0
> > * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
> >
> > Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
> > pkts bytes target prot opt in out source destination
> >
> >
> >
> > And these are the various offload parameters as set
> > at boot:
> >
> >
> > 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
> >
> >
> > To disable all checksuming I run the following
> > commands:
> > dom0:
> >
> > 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
> >
> > domU
> >
> > sudo ethtool -K eth0 tx off sg off tso off gso off gro off
> >
> >
> > 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.
> >
> >
> > 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.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
> >
> >
> > I hope this information is enough. If I can provide
> > anything else to help debug or test, please just
> > ask! ;)
> >
> > Thanks in advance,
> > Luís
> >
> >
> > > >
> > > > Thanks,
> > > > Luís
> > > >
> > > > On Tue, 2010-06-01 at 18:20 -0700, Jeremy Fitzhardinge wrote:
> > > >> On 06/01/2010 05:38 PM, Luís 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...
> > > >>
> > > >> 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).
> > > >>
> > > >> J
> > > >>
> > > >> >
> > > >> > Here is the bridge:
> > > >> > ifconfig virbr0
> > > >> > virbr0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff
> > > >> >
> > >
> > > 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: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
> > > >> > 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 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), Request 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), Request 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)
> > > >> >
> > >
> > > 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 192.168.120.1 tell 192.168.120.254, length 28
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> >
> > > >> >
> > > >> > 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 192.168.120.1 tell 192.168.120.254, length 28
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> >
> > > 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> > > >> > 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
> > > >> > 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
> > > >> > 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
> > > >> >
> > > >> >
> > > >> >
> > > >> > 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ís
> > > >> >
> > > >> >
> > > >> > _______________________________________________
> > > >> > Xen-devel mailing list
> > > >> > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com>
> > > >> > http://lists.xensource.com/xen-devel
> > > >> >
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Xen-devel mailing list
> > > >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com>
> > > >> http://lists.xensource.com/xen-devel
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
> >
> >
> > -----Inline Attachment Follows-----
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
>
>
>
>
>
> -----Inline Attachment Follows-----
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
[-- Attachment #1.1.2: Type: text/html, Size: 31276 bytes --]
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-06-03 23:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 0:38 ARP problems with xen 4.0 with pvops kernel Luís Silva
2010-06-02 1:20 ` Jeremy Fitzhardinge
2010-06-02 8:47 ` [Xen-devel] " Luís Silva
2010-06-02 16:06 ` Jeremy Fitzhardinge
2010-06-02 18:53 ` Luís Silva
2010-06-02 19:26 ` Re: [Xen-devel] " Boris Derzhavets
2010-06-03 10:20 ` [Xen-users] " Luís Silva
2010-06-03 10:59 ` Re: [Xen-devel] " Boris Derzhavets
2010-06-03 23:18 ` Luís Silva [this message]
2010-06-06 10:19 ` Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel 2.6.32.15 Boris Derzhavets
2010-06-06 16:43 ` [Xen-users] " Jeremy Fitzhardinge
2010-06-02 7:09 ` ARP problems with xen 4.0 with pvops kernel Boris Derzhavets
2010-06-02 7:10 ` Sander Eikelenboom
2010-06-02 8:00 ` [Xen-users] " Boris Derzhavets
2010-06-03 9:35 ` Boris Derzhavets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1275607101.2138.24.camel@luis-port \
--to=luis.silva@axiomasoft.pt \
--cc=bderzhavets@yahoo.com \
--cc=jeremy@goop.org \
--cc=xen-devel@lists.xensource.com \
--cc=xen-users@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).