I must be doing something wrong: Have set up a basic Xen system, Dom0 + one Xen0 guest. Configured for a routed network. Ping Dom0 -> guest works. Ping guest -> Dom0 works. nmap Dom0 -> guest reports port 22 open. Ssh Dom0 -> guest hangs. ssh guest -> Dom0 hangs. Same behaviour. Watching a packet capture shows traffic passing but with retransmits and poor performance. If I build a gre tunnel between Dom0 and guest, everything works fine, with the exception that I must generate some traffic from the guest first. I have no iptables rules configured, so it''s not that. Looks like there is maybe some issue with tcp traffic between domains. Looks like a bug to me, but I''m posting to the user list first. I am running unstable from last friday. Tim:> _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Monday 08 August 2005 15:34, Tim Durack wrote:> I must be doing something wrong: > > Have set up a basic Xen system, Dom0 + one Xen0 guest. Configured for > a routed network. > > Ping Dom0 -> guest works. > Ping guest -> Dom0 works. > > nmap Dom0 -> guest reports port 22 open. > > Ssh Dom0 -> guest hangs. > ssh guest -> Dom0 hangs. Same behaviour. Watching a packet capture > shows traffic passing but with retransmits and poor performance. > > If I build a gre tunnel between Dom0 and guest, everything works fine, > with the exception that I must generate some traffic from the guest > first. > > I have no iptables rules configured, so it''s not that. Looks like > there is maybe some issue with tcp traffic between domains. > > Looks like a bug to me, but I''m posting to the user list first.There was a long thread about this problem maybe one or two weeks ago... I think the problem was that the virtual eth devices had packet queueing disabled (txqueuelen:0 on ifconfig), and had a 4k size max. ring buffer for transfering packets between domains. Whenever that buffer would run full, packets are dropped... /Ernst _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ernst Bachmann wrote:> On Monday 08 August 2005 15:34, Tim Durack wrote: > >>I must be doing something wrong: >> >>Have set up a basic Xen system, Dom0 + one Xen0 guest. Configured for >>a routed network. >> >>Ping Dom0 -> guest works. >>Ping guest -> Dom0 works. >> >>nmap Dom0 -> guest reports port 22 open. >> >>Ssh Dom0 -> guest hangs. >>ssh guest -> Dom0 hangs. Same behaviour. Watching a packet capture >>shows traffic passing but with retransmits and poor performance. >> >>If I build a gre tunnel between Dom0 and guest, everything works fine, >>with the exception that I must generate some traffic from the guest >>first. >> >>I have no iptables rules configured, so it''s not that. Looks like >>there is maybe some issue with tcp traffic between domains. >> >>Looks like a bug to me, but I''m posting to the user list first. > > > There was a long thread about this problem maybe one or two weeks ago... > I think the problem was that the virtual eth devices had packet queueing > disabled (txqueuelen:0 on ifconfig), and had a 4k size max. ring buffer for > transfering packets between domains. > Whenever that buffer would run full, packets are dropped...A too-small network buffer should never be able to hang a system; then again, it''s unclear what Tim means by ''hang''. -- Kind regards, Mogens Valentin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
The domain does not hang, the ssh session doesn''t respond presumably because it is waiting for a response across the network. Looking through the archives it does look like others have run into this issue. I think I''ll have to go back to stable for now. Tim:> _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tuesday 09 August 2005 14:38, Tim Durack wrote:> The domain does not hang, the ssh session doesn''t respond presumably > because it is waiting for a response across the network. > > Looking through the archives it does look like others have run into > this issue. I think I''ll have to go back to stable for now.Havn''t tried myself, but this might help: o use a dedicated CPU for the driver domain on a SMP system, that way the queue is emptied faster, thus less overflows. o try to "ifconfig vif1.0 txqueuelen 100" on dom0, and retest with it (with the correct vif, of course) changing the txqueuelen with ifconfig might make things worse, tho, I don''t know enough about the vif code to comment that... /Ernst _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks for the suggestions. Unfotunately it is a Pentium-M laptop that I''m building a router test bed on, so SMP isn''t going to help any in this case. I''ll try the txqueuelen thing and see what happens. I''m a little suprised by this network behaviour, I had no such problems running 2.0 unstable. Tim:> _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I''ll try the txqueuelen thing and see what happens.FWIW, setting the txqueuelen on my vif''s didn''t resolve the issue here. John -- John Madden UNIX Systems Engineer Ivy Tech Community College of Indiana jmadden@ivytech.edu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
txqueuelen didn''t work here either. For what it''s worth, here''s what the capture looks like for Dom0 -> guest: tethereal -i eth0 device eth0 entered promiscuous mode Capturing on eth0 0.000000 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=122820 TSER=0 WS=2 0.002181 192.168.1.2 -> 192.168.1.1 TCP ssh > 59135 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=115220 TSER=122820 WS=1 0.003497 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=122820 TSER=115220 0.010001 192.168.1.2 -> 192.168.1.1 SSH Server Protocol: SSH-2.0-OpenSSH_4.1p1 Debian-6 0.010472 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [ACK] Seq=1 Ack=32 Win=5840 Len=0 TSV=122821 TSER=115221 0.010478 192.168.1.1 -> 192.168.1.2 SSH Client Protocol: SSH-2.0-OpenSSH_4.1p1 Debian-6 0.215968 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] Client: Unknown (46)[Unreassembled Packet [incorrect TCP checksum]] 0.635966 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] Client: Unknown (46) 1.475967 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] Client: Unknown (46) 3.155992 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] Client: Unknown (46) 5.466528 192.168.1.2 -> fe:ff:ff:ff:ff:ff ARP Who has 192.168.1.1? Tell 192.168.1.2 5.466572 192.168.1.1 -> 192.168.1.2 ARP 192.168.1.1 is at fe:ff:ff:ff:ff:ff 6.515988 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] Encrypted request packet len=31 13.235996 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] Encrypted request packet len=31 Interestingly if I build two guests I can ssh between them just fine. Tim:> _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tim Durack wrote:> txqueuelen didn''t work here either. > > For what it''s worth, here''s what the capture looks like for Dom0 -> guest:For a temporary workaround, could you disable checksumming: ethtool -K tx off in each domain? thanks, Nivedita> tethereal -i eth0 > device eth0 entered promiscuous mode > Capturing on eth0 > 0.000000 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [SYN] Seq=0 > Ack=0 Win=5840 Len=0 MSS=1460 TSV=122820 TSER=0 WS=2 > 0.002181 192.168.1.2 -> 192.168.1.1 TCP ssh > 59135 [SYN, ACK] > Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=115220 TSER=122820 WS=1 > 0.003497 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [ACK] Seq=1 > Ack=1 Win=5840 Len=0 TSV=122820 TSER=115220 > 0.010001 192.168.1.2 -> 192.168.1.1 SSH Server Protocol: > SSH-2.0-OpenSSH_4.1p1 Debian-6 > 0.010472 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [ACK] Seq=1 > Ack=32 Win=5840 Len=0 TSV=122821 TSER=115221 > 0.010478 192.168.1.1 -> 192.168.1.2 SSH Client Protocol: > SSH-2.0-OpenSSH_4.1p1 Debian-6 > 0.215968 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > Client: Unknown (46)[Unreassembled Packet [incorrect TCP checksum]] > 0.635966 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > Client: Unknown (46) > 1.475967 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > Client: Unknown (46) > 3.155992 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > Client: Unknown (46) > 5.466528 192.168.1.2 -> fe:ff:ff:ff:ff:ff ARP Who has 192.168.1.1? > Tell 192.168.1.2 > 5.466572 192.168.1.1 -> 192.168.1.2 ARP 192.168.1.1 is at fe:ff:ff:ff:ff:ff > 6.515988 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > Encrypted request packet len=31 > 13.235996 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > Encrypted request packet len=31 > > > Interestingly if I build two guests I can ssh between them just fine. > > Tim:> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tried "ethtool -K eth0 tx off" for both guest domains (doesn''t work in Dom0.) Still the same problem. The capture shows TCP checksum problems, so I assume that is the root of the problem. Tim:> On 8/9/05, Nivedita Singhvi <niv@us.ibm.com> wrote:> Tim Durack wrote: > > txqueuelen didn''t work here either. > > > > For what it''s worth, here''s what the capture looks like for Dom0 -> guest: > > For a temporary workaround, could you disable checksumming: > > ethtool -K tx off > > in each domain? > > thanks, > Nivedita > > > > tethereal -i eth0 > > device eth0 entered promiscuous mode > > Capturing on eth0 > > 0.000000 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [SYN] Seq=0 > > Ack=0 Win=5840 Len=0 MSS=1460 TSV=122820 TSER=0 WS=2 > > 0.002181 192.168.1.2 -> 192.168.1.1 TCP ssh > 59135 [SYN, ACK] > > Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=115220 TSER=122820 WS=1 > > 0.003497 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [ACK] Seq=1 > > Ack=1 Win=5840 Len=0 TSV=122820 TSER=115220 > > 0.010001 192.168.1.2 -> 192.168.1.1 SSH Server Protocol: > > SSH-2.0-OpenSSH_4.1p1 Debian-6 > > 0.010472 192.168.1.1 -> 192.168.1.2 TCP 59135 > ssh [ACK] Seq=1 > > Ack=32 Win=5840 Len=0 TSV=122821 TSER=115221 > > 0.010478 192.168.1.1 -> 192.168.1.2 SSH Client Protocol: > > SSH-2.0-OpenSSH_4.1p1 Debian-6 > > 0.215968 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > > Client: Unknown (46)[Unreassembled Packet [incorrect TCP checksum]] > > 0.635966 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > > Client: Unknown (46) > > 1.475967 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > > Client: Unknown (46) > > 3.155992 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > > Client: Unknown (46) > > 5.466528 192.168.1.2 -> fe:ff:ff:ff:ff:ff ARP Who has 192.168.1.1? > > Tell 192.168.1.2 > > 5.466572 192.168.1.1 -> 192.168.1.2 ARP 192.168.1.1 is at fe:ff:ff:ff:ff:ff > > 6.515988 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > > Encrypted request packet len=31 > > 13.235996 192.168.1.1 -> 192.168.1.2 SSHv2 [TCP Retransmission] > > Encrypted request packet len=31 > > > > > > Interestingly if I build two guests I can ssh between them just fine. > > > > Tim:> > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Tried "ethtool -K eth0 tx off" for both guest domains (doesn''t work in Dom0.) > > Still the same problem. The capture shows TCP checksum problems, so I > assume that is the root of the problem.Perhaps it''s a driver-specific thing, but from a guest: guest:~# ethtool -K eth0 tx off Cannot set device tx csum settings: Operation not supported ...So I''m not able to test this workaround. John -- John Madden UNIX Systems Engineer Ivy Tech Community College of Indiana jmadden@ivytech.edu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
For me the command toggles the appropriate flag, but doesn''t fix the problem. On 8/10/05, John Madden <jmadden@ivytech.edu> wrote:> > Tried "ethtool -K eth0 tx off" for both guest domains (doesn''t work in Dom0.) > > > > Still the same problem. The capture shows TCP checksum problems, so I > > assume that is the root of the problem. > > Perhaps it''s a driver-specific thing, but from a guest: > > guest:~# ethtool -K eth0 tx off > Cannot set device tx csum settings: Operation not supported > > ...So I''m not able to test this workaround. > > John > > > > > > -- > John Madden > UNIX Systems Engineer > Ivy Tech Community College of Indiana > jmadden@ivytech.edu > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John Madden wrote:>>Tried "ethtool -K eth0 tx off" for both guest domains (doesn''t work in Dom0.) >> >>Still the same problem. The capture shows TCP checksum problems, so I >>assume that is the root of the problem. > > > Perhaps it''s a driver-specific thing, but from a guest: > > guest:~# ethtool -K eth0 tx off > Cannot set device tx csum settings: Operation not supported > > ...So I''m not able to test this workaround.Right, it is. Which card/driver are you using? thanks, Nivedita _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Right, it is. Which card/driver are you using?Broadcomm / tg3. John -- John Madden UNIX Systems Engineer Ivy Tech Community College of Indiana jmadden@ivytech.edu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John Madden wrote:>>Right, it is. Which card/driver are you using? > > > Broadcomm / tg3. > > JohnUnfortunately, that''s not an easily configurable driver. If you don''t mind recompiling the kernel, try editing the driver and turning off NETIF_F_IP_CSUM, i.e. force dev->features &= ~NETIF_F_IP_CSUM as a quick short-term test. thanks, Nivedita _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Unfortunately, that''s not an easily configurable > driver. If you don''t mind recompiling the kernel, > try editing the driver and turning off NETIF_F_IP_CSUM, > i.e. force dev->features &= ~NETIF_F_IP_CSUM as > a quick short-term test.I''ve got only a production install of Xen, and while the kernel is a custom build of 2.0.6-testing, it can''t really be rebooted at the moment. It looks like it hasn''t fixed the issue for Tim, so it doesn''t seem promising anyway. We''ve spoken earlier about switching to routed guests rather than bridged and you talked about producing a README on the setup of that configuration. Is that available? Do we think routing would fix the problem? John -- John Madden UNIX Systems Engineer Ivy Tech Community College of Indiana jmadden@ivytech.edu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I''m using tg3 also. I tried the NETIF hack, this just appears to force RX checksumming off, which doesn''t fix the problem either. Unfortunately I am experiencing these problems in a routed environment... Any other ideas? On 8/10/05, John Madden <jmadden@ivytech.edu> wrote:> > Unfortunately, that''s not an easily configurable > > driver. If you don''t mind recompiling the kernel, > > try editing the driver and turning off NETIF_F_IP_CSUM, > > i.e. force dev->features &= ~NETIF_F_IP_CSUM as > > a quick short-term test. > > I''ve got only a production install of Xen, and while the kernel is a custom build > of 2.0.6-testing, it can''t really be rebooted at the moment. It looks like it > hasn''t fixed the issue for Tim, so it doesn''t seem promising anyway. > > We''ve spoken earlier about switching to routed guests rather than bridged and you > talked about producing a README on the setup of that configuration. Is that > available? Do we think routing would fix the problem? > > John > > > > -- > John Madden > UNIX Systems Engineer > Ivy Tech Community College of Indiana > jmadden@ivytech.edu > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tim Durack wrote:> I''m using tg3 also. I tried the NETIF hack, this just appears to force > RX checksumming off, which doesn''t fix the problem either.Should also force tx off, which should avoid one of the problems that needs fixing.> Unfortunately I am experiencing these problems in a routed environment... > > Any other ideas?I don''t believe anyone else has seen the checksum errors before - so I''m inclined to believe your problem is not the same as those we are currently investigating for other issues..It would be good to nail this down. Would you be ok with turning on DBG? thanks, Nivedita>>>Unfortunately, that''s not an easily configurable >>>driver. If you don''t mind recompiling the kernel, >>>try editing the driver and turning off NETIF_F_IP_CSUM, >>>i.e. force dev->features &= ~NETIF_F_IP_CSUM as >>>a quick short-term test. >> >>I''ve got only a production install of Xen, and while the kernel is a custom build >>of 2.0.6-testing, it can''t really be rebooted at the moment. It looks like it >>hasn''t fixed the issue for Tim, so it doesn''t seem promising anyway. >> >>We''ve spoken earlier about switching to routed guests rather than bridged and you >>talked about producing a README on the setup of that configuration. Is that >>available? Do we think routing would fix the problem? >> >>John >> >> >> >>-- >>John Madden >>UNIX Systems Engineer >>Ivy Tech Community College of Indiana >>jmadden@ivytech.edu >> >> > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John Madden wrote:>>Unfortunately, that''s not an easily configurable >>driver. If you don''t mind recompiling the kernel, >>try editing the driver and turning off NETIF_F_IP_CSUM, >>i.e. force dev->features &= ~NETIF_F_IP_CSUM as >>a quick short-term test. > > > I''ve got only a production install of Xen, and while the kernel is a custom build > of 2.0.6-testing, it can''t really be rebooted at the moment. It looks like it > hasn''t fixed the issue for Tim, so it doesn''t seem promising anyway.Yes, I don''t think that will help - but we''re hoping to clear up a few bugs in the next couple of days, so perhaps you might want to hold off on trying routing or something else just yet. I can''t suggest anything other than trying to get more info out of the system at the moment (tcp traces, logs, etc). thanks, Nivedita _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
It''s a test box so I can compile/reboot freely until the problem is fixed :-] I''m asuming debug is a compile time flag...I''ll probably need some direction to provide useful feedback. Tim:> On 8/10/05, Nivedita Singhvi <niv@us.ibm.com> wrote:> Tim Durack wrote: > > I''m using tg3 also. I tried the NETIF hack, this just appears to force > > RX checksumming off, which doesn''t fix the problem either. > > Should also force tx off, which should avoid one of the > problems that needs fixing. > > > Unfortunately I am experiencing these problems in a routed environment... > > > > Any other ideas? > > I don''t believe anyone else has seen the checksum errors > before - so I''m inclined to believe your problem is not > the same as those we are currently investigating for > other issues..It would be good to nail this down. > > Would you be ok with turning on DBG? > > thanks, > Nivedita > > >>>Unfortunately, that''s not an easily configurable > >>>driver. If you don''t mind recompiling the kernel, > >>>try editing the driver and turning off NETIF_F_IP_CSUM, > >>>i.e. force dev->features &= ~NETIF_F_IP_CSUM as > >>>a quick short-term test. > >> > >>I''ve got only a production install of Xen, and while the kernel is a custom build > >>of 2.0.6-testing, it can''t really be rebooted at the moment. It looks like it > >>hasn''t fixed the issue for Tim, so it doesn''t seem promising anyway. > >> > >>We''ve spoken earlier about switching to routed guests rather than bridged and you > >>talked about producing a README on the setup of that configuration. Is that > >>available? Do we think routing would fix the problem? > >> > >>John > >> > >> > >> > >>-- > >>John Madden > >>UNIX Systems Engineer > >>Ivy Tech Community College of Indiana > >>jmadden@ivytech.edu > >> > >> > > > > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tim Durack wrote:> It''s a test box so I can compile/reboot freely until the problem is fixed :-] > > I''m asuming debug is a compile time flag...I''ll probably need some > direction to provide useful feedback. > > Tim:>Cool! Look in xen/Rules.mk: verbose ?= n debug ?= n perfc ?= n perfc_arrays?= n trace ?= n optimize ?= y domu_debug ?= n crash_debug ?= n I would change the above defaults, to save typing in all that in the make line. Turn on verbose and *debug*, do a make clean, rebuild and run. thanks, Nivedita _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Okay, did that. How do I get any useful debug information? On 8/10/05, Nivedita Singhvi <niv@us.ibm.com> wrote:> Tim Durack wrote: > > It''s a test box so I can compile/reboot freely until the problem is fixed :-] > > > > I''m asuming debug is a compile time flag...I''ll probably need some > > direction to provide useful feedback. > > > > Tim:> > > Cool! Look in xen/Rules.mk: > > verbose ?= n > debug ?= n > perfc ?= n > perfc_arrays?= n > trace ?= n > optimize ?= y > domu_debug ?= n > crash_debug ?= n > > I would change the above defaults, to save typing in all > that in the make line. Turn on verbose and *debug*, do > a make clean, rebuild and run. > > thanks, > Nivedita >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tim Durack wrote:> Okay, did that. How do I get any useful debug information?Looking in /var/log/messages is always useful. Also, examine /var/log/xend.log. BTW, this will go much faster on IRC :). thanks, Nivedita> On 8/10/05, Nivedita Singhvi <niv@us.ibm.com> wrote: > >>Tim Durack wrote: >> >>>It''s a test box so I can compile/reboot freely until the problem is fixed :-] >>> >>>I''m asuming debug is a compile time flag...I''ll probably need some >>>direction to provide useful feedback. >>> >>>Tim:> >> >>Cool! Look in xen/Rules.mk: >> >>verbose ?= n >>debug ?= n >>perfc ?= n >>perfc_arrays?= n >>trace ?= n >>optimize ?= y >>domu_debug ?= n >>crash_debug ?= n >> >>I would change the above defaults, to save typing in all >>that in the make line. Turn on verbose and *debug*, do >>a make clean, rebuild and run. >> >>thanks, >>Nivedita >> > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Okay, fixed it by using a bridged setup. This doesn''t work: Dom0 vif1.0 <-> guest eth0 This does work: Dom0 vif0.0 bridged with Dom0 vif1.0. Ip address applied to Dom0 veth0 and guest eth0. Would be much simpler in my mind if the first scenario worked as expected... Tim:> On 8/8/05, Tim Durack <tdurack@gmail.com> wrote:> I must be doing something wrong: > > Have set up a basic Xen system, Dom0 + one Xen0 guest. Configured for > a routed network. > > Ping Dom0 -> guest works. > Ping guest -> Dom0 works. > > nmap Dom0 -> guest reports port 22 open. > > Ssh Dom0 -> guest hangs. > ssh guest -> Dom0 hangs. Same behaviour. Watching a packet capture > shows traffic passing but with retransmits and poor performance. > > If I build a gre tunnel between Dom0 and guest, everything works fine, > with the exception that I must generate some traffic from the guest > first. > > I have no iptables rules configured, so it''s not that. Looks like > there is maybe some issue with tcp traffic between domains. > > Looks like a bug to me, but I''m posting to the user list first. > > I am running unstable from last friday. > > Tim:> >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Okay, fixed it by using a bridged setup.Sorry, fixed what by using a bridged setup? The intermittent packet loss? John -- John Madden UNIX Systems Engineer Ivy Tech Community College of Indiana jmadden@ivytech.edu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
If I configure Dom0 vif1.0 <-> guest eth0, I can ping between the two, but not ssh. Packet capture shows ethereal complaining about tcp checksum problems. Tried all kinds of enabling/disabling offload settings. Creating a gre tunnel between the two domains works, presumably because whatever the checksum offload problem is, it gets avoided by adding another header. Configuring Dom0 veth0/vif0.0/vif1.0/br0 <-> guest eth0 bridging works as expected. Tim:> On 8/17/05, John Madden <jmadden@ivytech.edu> wrote:> > Okay, fixed it by using a bridged setup. > > Sorry, fixed what by using a bridged setup? The intermittent packet loss? > > John > > > > > -- > John Madden > UNIX Systems Engineer > Ivy Tech Community College of Indiana > jmadden@ivytech.edu > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users