qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] First UDP packet dropped after initial ARP request/reply


From: Jakub Jermar
Subject: [Qemu-devel] First UDP packet dropped after initial ARP request/reply
Date: Fri, 20 Apr 2012 12:17:13 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

Hi,

I am observing an interesting phenomenon on the latest QEMU git and the
latest HelenOS mainline (the problem is likely guest-neutral though).
The QEMU command line is as follows:

$ qemu-system-i386 -device rtl8139,vlan=0 -net user -boot d -redir \
  udp:8080::8080 -redir udp:8081::8081 -redir tcp:8080::8080 -redir \
  tcp:8081::8081 -cdrom image.iso

Now after I configure networking in HelenOS and start listening on the
8080 UDP port, I do this on the host as the first networking activity:

$ echo foo | nc -u 127.0.0.1 8080

What I observe inside HelenOS is an ARP request from 10.0.2.2. After
HelenOS replies, there is no more network traffic, i.e. the UDP datagram
is not retransmitted. But when repeat the nc command for the second
time, the datagram gets normally through without any additional ARP
requests.

This makes me think that QEMU for some reason does not attempt to
retransmit the UDP packet after it learns the MAC address of 10.0.2.15.

I collected QEMU networking trace, the relevant part seems to be this:

if_start...
if_start...
if_start...
if_start...
sorecvfrom...
 so = 232db0a8
m_get...
 m = 2334a808
 did recvfrom 4, errno = 11-Resource temporarily unavailable
udp_output...
 so = 232db0a8
 m = 2334a808
 saddr = 202000a
 daddr = f02000a
ip_output...
 so = 232db0a8
 m0 = 2334a808
if_output...
 so = 232db0a8
 ifm = 2334a808
if_start...
arp_table_search...
 ip = 0xf02000a

[1295 more instances of arp_table_search]

if_start...
arp_table_search...
 ip = 0xf02000a
if_start...
m_free...
 m = 2334a808
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
if_start...
ip_slowtimo...
tcp_slowtimo...
if_start...
if_start...

[end of emulation]
[slirp cleanup]

There is a HelenOS ticket for this also:

  http://trac.helenos.org/ticket/442

Is this a known SLIRP issue or am I missing something important here?

Jakub



reply via email to

[Prev in Thread] Current Thread [Next in Thread]