Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Apr 2015 15:24:17 -0700
From:      Charles Swiger <cswiger@mac.com>
To:        Yuri <yuri@rawbw.com>
Cc:        Brooks Davis <brooks@freebsd.org>, net@freebsd.org
Subject:   Re: [BUG?] dhclient sends packets with source IP address that has been deleted
Message-ID:  <B1957BA9-80A5-404B-99F3-85AAFA521C4E@mac.com>
In-Reply-To: <5524472C.1050905@rawbw.com>
References:  <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> <5524472C.1050905@rawbw.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 7, 2015, at 2:07 PM, Yuri <yuri@rawbw.com> wrote:
> On 04/07/2015 07:53, Brooks Davis wrote:
>> I suppose that since dhclient has been killed and restarted it can't
>> know it's on the same network, but in practice you want to try to get
>> the same lease again and fall back if it turns out you've moved or =
your dhcp
>> server is broken and lost state.  I don't see how this would hurt =
anything.
>=20
> Let's say dhclient is restarted after a while (ex. after the reboot), =
when some other host already has that same IP address. dhclient sends =
the broadcast with it, and the response will be sent to another host, =
which currently has that address, and that other host will discard this =
response. dhclient keeps trying for many seconds, doesn't get any =
response. Then it falls back to sending from 0.0.0.0->255.255.255.255 =
(as it should have done in the first place), and immediately gets the =
valid response. The problem delays DHCP handshake, this is how this can =
hurt.

In point of fact, the IP used for the source address doesn't matter too =
much for DHREQUESTs because they are subnet local (by definition), and =
the replies will reach the original sender because they are addressed to =
the layer-2 MAC address of that host.  DHCP operates as much on layer-2 =
as layer-3 and dhclient, ISC dhcpd, and other DHCP software should =
handle such cases.

There is a specific protocol coming from Zeroconf defined here:

  http://www.ietf.org/rfc/rfc5227.txt =
<http://www.ietf.org/rfc/rfc5227.txt>;

...which talks about how to handle potential IP conflicts via ARP =
probing.

Regards,
--=20
-Chuck




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1957BA9-80A5-404B-99F3-85AAFA521C4E>