Why is qemu issuing a DHCP discover after it receives a DHCP offer

Question

I'm having some trouble seting up network on qemu. I'm trying the easy option (user). The qemu command I run is this:

./qemu-xilinx/arm-softmmu/qemu-system-arm \
      -M xilinx-zynq-a9 -m 1024 -serial null -serial mon:stdio \
      -dtb /homes/cperivol/Sandbox/xilinx-zynq-bootstrap/resources/devicetree.dtb \
      -kernel /homes/cperivol/Sandbox/xilinx-zynq-bootstrap/resources/zImage \
      -initrd /homes/cperivol/Sandbox/xilinx-zynq-bootstrap/resources.qemu/ramdisk.img \
      -nographic -s -net dump,file=/tmp/dhcpdump.pcap -net nic \
      -net user,net=192.168.1.0/24

The interesting part of the command is at the end. I basically dump all TCP/UDP traffic to /tmp/dhcpdump.pcap.

Then from qemu I do:

$ udhcpc -t 1 -T 10 -n
udhcpc (v1.22.0.git) started
Sending discover...
No lease, failing

And from the host I read from the dump with thcpdump:

(host) $ tcpdump -e -v -s 0 -nr /tmp/dhcpdump.pca

[*other very similar requests done by the kernel at startup*]

15:00:48.874298 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x10, ttl 64, id 20, offset 0, flags [none], proto UDP (17), length 576)
    192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548, xid 0x7a5d3455, Flags [none]
      Your-IP 192.168.1.15
      Server-IP 192.168.1.2
      Client-Ethernet-Address 4a:3d:06:fb:d3:52
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 192.168.1.2
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 192.168.1.2
        Domain-Name-Server Option 6, length 4: 192.168.1.3
        Lease-Time Option 51, length 4: 86400
15:00:48.874348 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 312)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284, xid 0x7a5d3455, Flags [none]
      Client-Ethernet-Address 4a:3d:06:fb:d3:52
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Client-ID Option 61, length 7: ether 4a:3d:06:fb:d3:52
        MSZ Option 57, length 2: 576
        Parameter-Request Option 55, length 7: 
          Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
          Domain-Name, BR, NTP
        Vendor-Class Option 60, length 16: "udhcp 1.22.0.git"

The problem is that I can't get a lease but from an academic perspective I'm most interested into why I get the offer before the client issues discover.

EDIT: here is the full dump as well:

(host) $ tcpdump -e -s 0 -nr /tmp/dhcpdump.pcap 
reading from file /tmp/dhcpdump.pcap, link-type EN10MB (Ethernet)
14:34:12.400162 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:34:12.400203 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:34:14.518984 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:34:14.519023 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:34:18.227926 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:34:18.227976 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:34:24.718934 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:34:24.719064 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:34:36.072184 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:34:36.072301 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:34:55.938462 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:34:55.938583 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:35:21.051476 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:35:21.051526 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:35:22.872058 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:35:22.872175 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:35:26.055294 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:35:26.055339 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:35:31.619870 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:35:31.619966 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:35:41.351737 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:35:41.351798 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:35:58.377559 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:35:58.377601 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 548
14:51:15.522553 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:51:15.522601 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
14:51:18.060428 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:51:18.060460 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
14:52:22.487889 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:52:22.487939 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
14:52:30.883654 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:52:30.883691 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
14:52:39.279423 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:52:39.279462 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
14:59:42.818215 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
14:59:42.818263 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
15:00:07.938782 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
15:00:07.938829 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
15:00:28.348337 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
15:00:28.348378 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284
15:00:48.874298 52:55:c0:a8:01:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
15:00:48.874348 4a:3d:06:fb:d3:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:3d:06:fb:d3:52, length 284

Using 'net user' you use "internal" dhcpd inside qemu. I doubt the tcpdump output shows the traffic from this qemu instance. Why? IIUC when using 'net user' the qemu VM doesn't create a tap interface. So how could tcpdump on the host "sniff" a traffic which exists only in userspace? Please clarify mac address and on which iface you were capturing data with tcpdump. — jirib, Feb 27 '17 at 09:51

Why is qemu issuing a DHCP discover after it receives a DHCP offer

0 Answers0