<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1538650997009_75720">Hi Simon,</div><div id="yui_3_16_0_ym19_1_1538650997009_75883"> Sorry to come back to this question again. You wrote:</div><pre id="yui_3_16_0_ym19_1_1538650997009_75956" style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">"I don't think it would be possible to make this hack any more safe by
doing the ping-check before re-creating the lease. The whole premise is
that the client attempting to renew is already configured, but the
server lost track of it. So doing a ping-check would expect to get a
reply from the already-configured client."
<font id="yui_3_16_0_ym19_1_1538650997009_76148" face="times new roman, new york, times, serif"><span id="yui_3_16_0_ym19_1_1538650997009_76152" style="display: inline !important; float: none; background-color: transparent; color: rgb(0, 0, 0); font-family: Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Well, actually, I see at least two ways to improve that behavior, especially starting from the fact that assuming that the lease dB was corrupted is weird and not safe:<br>1. ARP the IP to see if you receive any answer other than the client asking the IP (more efficient but fails if using proxy arp).<br>2. PING the IP and expect to receive an answer from that same MAC (might fail if device is set to not answer ping).<br>if not, then reject and force 4 way. Indeed, if you receive no answer, you can no longer assume that this is the legit owner of the IP. Anyway, if the client is legitimate, the algorithm will most probably give him the same IP.<br>The main drawback is an increased handling time, but that only occurs if the lease is unknown.</span>
</font></pre><div id="yui_3_16_0_ym19_1_1538650997009_75957" dir="ltr"><b id="yui_3_16_0_ym19_1_1538650997009_75958"></b><i id="yui_3_16_0_ym19_1_1538650997009_75959"></i><u id="yui_3_16_0_ym19_1_1538650997009_75960"></u><sub id="yui_3_16_0_ym19_1_1538650997009_75961"></sub><sup id="yui_3_16_0_ym19_1_1538650997009_75962"></sup><strike id="yui_3_16_0_ym19_1_1538650997009_75963"></strike><font face="times new roman, new york, times, serif"></font><br></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Wednesday, 19 September 2018, 13:01, Simon Kelley <simon@thekelleys.org.uk> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div dir="ltr"><br clear="none"><br clear="none">On 19/09/18 11:09, Bernard CLABOTS wrote:<br clear="none">> Thanks a lot for this answer.<br clear="none">> <br clear="none">> Indeed, it is a special case as we have a simple two way Request/ACK,<br clear="none">> this is also what is seen with some implementations when quickly<br clear="none">> unplugging/re-plugging the cable, it is legal AFAIK.<br clear="none">> <br clear="none">> I also agree on the necessity to be efficient in case of loss of the<br clear="none">> lease dB.<br clear="none">> <br clear="none">> Yet reading the RFC-2131, I saw:<br clear="none">> If the client's request is invalid (e.g., the client has moved<br clear="none">> to a new subnet), servers SHOULD respond with a DHCPNAK message to<br clear="none">> the client. Servers SHOULD NOT respond if their information is not<br clear="none">> guaranteed to be accurate. For example, a server that identifies a<br clear="none">> request for an expired binding that is owned by another server SHOULD<br clear="none">> NOT respond with a DHCPNAK unless the servers are using an explicit<br clear="none">> mechanism to maintain coherency among the servers.<br clear="none">> <br clear="none">> **//___^Referring to the first sentence, I agree it is only a should.<br clear="none">> Though, the next sentence is, according to your explanation, also<br clear="none">> relevant in this case, so DNSMasq should not respond if the information<br clear="none">> is not guaranteed to be accurate. Which also means that changing the<br clear="none">> authoritative flag, we risk to end up in the exemplified case where<br clear="none">> DNSMasq cannot guarantee that the requested IP is belonging to another<br clear="none">> DHCP Server, so it should not NAK and we are going in circles...<br clear="none">> We can of course discuss whether the Request is invalid simply because<br clear="none">> that IP is currently used by another device while not even assigned<br clear="none">> through DHCP. I would argue that the DNSMasq code explicitly accept that<br clear="none">> requesting the IP of the server fulfills this condition, which IMHO is a<br clear="none">> similar case.<br clear="none">> **//___^<br clear="none">> Anyhow, moving forward to resolve the issue I face, is there any way to<br clear="none">> force the RFC behavior of NAK-ing and forcing the 4 way exchange?<br clear="none">> <br clear="none"><br clear="none">If you don't set dhcp-authoritative, then the client will eventually<br clear="none">move to the four-way exchange, but it may take some time, as it involves<br clear="none">time-outs. The reason for this is that the dnsmasq server has to assume<br clear="none">there are other DHCP servers on the network which may hold a lease for<br clear="none">the client.<br clear="none"><br clear="none">The differences in behaviour are these.<br clear="none"><br clear="none">Without dhcp-authoritative:<br clear="none"><br clear="none">1) A client sending DHCPREQUEST in init-reboot state which doesn't have<br clear="none">a lease in the database will be ignored.<br clear="none"><br clear="none">2) A client sending a DHCPREQUEST in rebind mode which doesn't have a<br clear="none">lease in the database will be ignored. In renew mode (ie unicast<br clear="none">request) it will get a DHCPNAK.<br clear="none"><br clear="none">3) A client sending a request with the wrong server-id will be ignored.<br clear="none"><br clear="none">With dhcp-authoritative<br clear="none"><br clear="none">1) A client sending DHCPREQUEST in init-reboot state which doesn't have<br clear="none">a lease will have the lease created<br clear="none"><br clear="none">2) A client sending a DHCPREQUEST in renew or rebind mode which doesn't<br clear="none">have a lease in the database will have a lease created.<br clear="none"><br clear="none">3) A client sending a request in INIT_REBOOT or SELECTING state with<br clear="none">the wrong server-id will get a DHCPNAK.<div class="yqt6764824188" id="yqtfd75447"><br clear="none"><br clear="none"><br clear="none">Cheers,<br clear="none"><br clear="none">Simon.<br clear="none"><br clear="none"><br clear="none"></div></div><br><br></div> </div> </div> </div></div></body></html>