Comment 48 for bug 218126
Revision history for this message
| Wolfgang (ubuntu-launchpad-wkraft) wrote | #48 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hello,
I posted allready in a duplicate bug, haven`t seen, that this is the main thread.
I was fighting with the same error described here. I installed Hiranos kernel (32-bit version) on my AMD Athlon X2 5600+ server.
With that kernel I am now able to get my network up and running, however the network connectivity is still broken for large data transfers.
I use right now Hardy Heron for Dom0 and my DomU Clients, all with the patched Kernel.
My problem is:
Every outgoing tcp-connection (from a domU) stalls and finally hangs, as soon as there is more data than a couple of bytes going out.
Doing a "ls -laR /" in an ssh-session is allready enough. As soon as I transfer in a second session a large file from my DomU-Guest with FTP to another physical server in the internet, IP connectivity to the DomU is not longer possible, till I kill both processes and wait some time.
It is no problem transfering large files etc. TO my domU server, the problem only occurs when sending data out.
I am running the routed network with public IP addresses on all interfaces. I was now able to trace the issue a little further:
running an scp from a virtual domU host to another physical server in the same datacenter i had four tcpdumps sniffing.
I stopped the scp when the connection was stalling.
domU eth0: reports 1627 packets (all packets to dest-ip)
dom0 vif1.0: reports 1627 packets (all packets to dest-ip)
dom0 eth0: reports 1295 packets (all packets to dest-ip)
destination: reports 1295 packtes (all packets from domU-ip)
So I realized, that the packet-loss happens in the dom0 and not longer in the eth0-vifX.X connection.
However communication with the dom0 itself is no problem, neither in or out. Comparing the dumps from both interfaces of dom0 I see, that just every 3rd to 6th packet is missing on eth0 and will be finally resend if not confirmed with an ACK.
I have no firewalling (empty iptables) in dom0
Any ideas??
Just repeating: There is no problem in the other direction: From outside TO domU....
Regards
Wolfgang
Wolfgang