diff options
| author | David Gibson <david@gibson.dropbear.id.au> | 2012-02-24 01:23:28 +0100 |
|---|---|---|
| committer | Jan Kiszka <jan.kiszka@siemens.com> | 2012-02-27 14:55:07 +0100 |
| commit | 90d7416ab13113ccd3891435eea8715c5f503460 (patch) | |
| tree | c1ef264562f2606ffaaef7bef1e8252810ecbe27 /hw | |
| parent | b87ffa163185e339f9f9f1e6dbc561e0f990442d (diff) | |
| download | qemu-90d7416ab13113ccd3891435eea8715c5f503460.zip qemu-90d7416ab13113ccd3891435eea8715c5f503460.tar.gz qemu-90d7416ab13113ccd3891435eea8715c5f503460.tar.bz2 | |
slirp: Fix assertion failure on rejected DHCP requests
The guest network stack might DHCPREQUEST an address that the slirp built
in dhcp server can't let it have - for example if the guest has an old
leases file from another network configuration. In this case the dhcp
server should and does reject the request and prepares to send a DHCPNAK
to the client.
However, in this case the daddr variable in bootp_reply() is set to
0.0.0.0. Shortly afterwards, it unconditionally attempts to pre-insert the
new client address into the ARP table. This causes an assertion failure in
arp_address_add() because of the 0.0.0.0 address.
According to RFC2131, DHCPNAK messages for clients on the same subnet
must be sent to the broadcast address (S3.2, subpoint 2).
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Diffstat (limited to 'hw')
0 files changed, 0 insertions, 0 deletions