[Xen-bugs] [Bug 449] Packets sent by dom0 to domU lost in domU between acceptance and userspace delivery

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

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