summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorVincent Palatin <vpalatin@chromium.org>2011-03-02 17:25:02 -0500
committerBlue Swirl <blauwirbel@gmail.com>2011-03-05 12:00:59 +0000
commit4ad692e5ff494e043f821fc743ecd7144a6f00d3 (patch)
treea60247ab922b1d6a4af7aeb1e636bbc880a9f67c
parent4485f0dc16ae2d0a60f20d5bedbdfb64da024264 (diff)
downloadqemu-4ad692e5ff494e043f821fc743ecd7144a6f00d3.tar.gz
qemu-4ad692e5ff494e043f821fc743ecd7144a6f00d3.tar.bz2
qemu-4ad692e5ff494e043f821fc743ecd7144a6f00d3.zip
net: fix qemu_can_send_packet logic
If any of the clients is not ready to receive (ie it has a can_receive callback and can_receive() returns false), we don't want to start sending, else this client may miss/discard the packet. I got this behaviour with the following setup : the emulated machine is using an USB-ethernet adapter, it is connected to the network using SLIRP and I'm dumping the traffic in a .pcap file. As per the following command line : -net nic,model=usb,vlan=1 -net user,vlan=1 -net dump,vlan=1,file=/tmp/pkt.pcap Every time that two packets are coming in a row from the host, the usb-net code will receive the first one, then returns 0 to can_receive call since it has a 1 packet long queue. But as the dump code is always ready to receive, qemu_can_send_packet will return true and the next packet will discard the previous one in the usb-net code. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
-rw-r--r--net.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/net.c b/net.c
index ec4745df31..72ac4cf5df 100644
--- a/net.c
+++ b/net.c
@@ -411,11 +411,11 @@ int qemu_can_send_packet(VLANClientState *sender)
}
/* no can_receive() handler, they can always receive */
- if (!vc->info->can_receive || vc->info->can_receive(vc)) {
- return 1;
+ if (vc->info->can_receive && !vc->info->can_receive(vc)) {
+ return 0;
}
}
- return 0;
+ return 1;
}
static ssize_t qemu_deliver_packet(VLANClientState *sender,