http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=449
------- Additional Comments From craig@xxxxxxxxxxxxxxxxxxxxx 2005-12-12 19:24
-------
Here's the README I've included in the tarball, pasted here for the benefit of
searchers and for easy reading:
Summary:
Programs running on a Xen domU on this host are unable to recieve
network
packets from the dom0, but send fine and communicate fine with any other
host.
It's worth emphasizing that the problem is ONLY with a Xen domU
recieving
data from the dom0. It does not affect the domU recieving data from
other
hosts over the bridge (yes, the bridge on the dom0), nor sending data to
the dom0. Data appears to be recived fine by the domU's kernel and
"lost"
at some later point in the network stack, before making it to userspace
system calls like read() or select().
It appears that the bridge is passing packets fine, but packets
incoming to
the domU (bucketgui) are getting lost somewhere between the level of the
kernel where libpcap can see them, and when they're passed to userspace.
libpcap can see the incoming packets; read() and select() can not.
In addition to the Xen domU 'bucketgui' I've also tested with a
`ttylinux'
xenU with both the same kernel as bucketgui (the domU kernel), and the
same
kernel as bucket (the dom0 kernel). `ttylinux' demonstrates the same
problems as shown above no matter which kernel is used.
This issue has been tested both with my custom kernels for my hardware
and
requirements, and with the stock Xen 3.0 no-PAE x86 kernels. Both
display
the problem.
A hardware/OS summary and a listing of various supplied system
information
follows. There's also an explanation of some of the attached info files
and dumps at the end of this document.
Hosts:
Bucket (Xen dom0):
Debian 3.1, used as a core network server, mail server, etc.
Dual 2.4GHz Xeon (older, no x86-64 etc)
Intel server board, e7000 chipset
4GB RAM (domU allocated ~1GB)
3Ware Escalade 8500-8 disk array, LVM disk management
e1000 PCI-X NIC
Bucketgui (Xen domU):
Debian 3.1, used as an LTSP server
Virtual domU, allocated 2.4GB RAM
Contents:
bucket_dmesg.txt dmesg text from `bucket'
bucketgui_dmesg.txt dmesg text from
`bucketgui'
bucket_netstat.txt `netstat -a -A unix -A
inet' output from `bucketgui'
bucketgui_netstat.txt `netstat -a -A unix -A inet'
output from `bucketgui'
bucket_sysinfo_hw.txt typescript of hardware info,
xen info from bucket
config-2.6.12.6-xen0 config of bucket's running
kernel
config-2.6.12.6-xenU config of bucketgui's running
kernel
bucket_lsmod.txt Listing of loaded
modules from bucket
bucketgui_lsmod.txt Listing of loaded
modules from bucketgui
bucket_iptables.txt `iptables -L -v -n'
output from bucket
bucketgui_iptables.txt `iptables -L -v -n' output from
bucketgui (it doesn't
have iptables enabled)
etc_xen_auto_bucketgui Xen config for bucketgui
nc_trace_bucketgui.strace strace of a run of netcat on
bucketgui, talking to
bucket
nc_trace_bucket.strace strace of corresponding run of
netcat on bucket,
talking to bucketgui
sysinfo_script_bucketgui.txt typescript of system info collection on
bucketgui
sysinfo_script_bucket.txt typescript of system info
collection on bucket
trace_bucket_clean.pcap libpcap trace of network
testing done between
bucketgui and
bucket,
as seen by a `tcpdump' on bucket, listening on br0.
trace_bucketgui_clean.pcap libpcap trace of network
testing done between
bucketgui and
bucket,
as seen by a `tcpdump' on bucketgui, listening on eth0
trace_bucketgui.pcap Unfiltered trace including
network noise, testing from
3rd host
trace_bucket.pcap Unfiltered trace
including network noise, testing from 3rd
host
The network traces need some more explanation. They were created by
starting tcpdumps on both the Xen dom0 and Xen domU, then doing a
series of
tests and checks. The dom0 and domU pinged each other with default
packet
sizes and then with larger packet sizes, and a 3rd host pinged both of
them. An ldapsearch was run from bucketgui to demonstrate the "real
world"
effect of the problem. A netcat session was run between bucketgui and
bucket, where each tried to send the other data. Despite what it
appears
in the tcpdump, netcat on bucketgui was able to send but not recieve (ie
netcat on bucket could recieve but not send). Similarly, the ldapsearch
never recieved a response.
The strace of the netcat session (a different one, sorry) demonstrates
this. The netcat on bucket "sees" both its outgoing data and the data
incoming from bucketgui. The netcat instance on bucketgui "sees" its own
outgoing data, but not incoming data from bucket.
Summary:
WTF?
--
Configure bugmail:
http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs
|
Home