[Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Albert ARIBAUD]

Hi again Nikita,

Le Fri, 20 Jan 2017 23:37:43 -0800
"Nikita N." <nikitan at operamail.com> a écrit:

> Hi,
> I confirm --dhcp-authoritative works *PERFECTLY* with all other
> clients. Meaning it works when client matches the IP layer address,
> and when Dst: Broadcast (ff:ff:ff:ff:ff:ff) and Src: 0.0.0.0
> (0.0.0.0) and Dst: 255.255.255.255 (255.255.255.255).
> Unfortunately my bugged client has IP Src bugged, and IP Dst gateway
> bugged.

OK, then , I guess the answer to my question "And it always matches the
IP layer address?" is "No", even though the example frame you gave had
the IP layer and DHCP layer IP adresses matching. I suspect this is not
a valid DHCP fame, but I could not find an explicit requirement in the
DHCP RFC about IP and DHCP layer client IP addresses having to match.

It may be, tough, that dnsmasq considers the frame dubious because of
the IP mispatch, and refrains from processing it at all.

> No matter that, I see those DHCP request frames in the server network
> where I run dnsmasq (because my net conf is so), so also dnsmasq sees
> them.

(I had no doubt that dnsmasq was seeing these frames.)

> I believe the option I'm looking for is smtng like: if a UDP frame
> with Dst Port: 67 comes from Src: macX, and is *NOT*
> protocol/standard valid, then dnsmasq sends a DHCP NAK with Dst: macX
> (e.g. similar to the different cases when dnsmasq sends NAK with
> option Message wrong network, whatever)
> Is that possible?

Everything is "possible". If by "possible" you mean "by just setting an
option", then answer is no; if you mean "is it ok if I write a patch
for this", nobody can (or should) prevent you from doing so; if you
mean "... and get this patch integrated in mainline dnsmasq", then only
Simon Kelley might tell. AFAIU, you are requesting a behavior not
explicitly specified in the DHCP RFC in order to match an out-of-RFC
client behavior; this may or may not be accepted by Simon.

I personally would not be in favor of adding such a feature to dnsmasq,
as it adds very specific source code, adds complexity, and affects
maintenability, for a situation which is apparently rare and caused
by a blatant bug in a not-widely-found third party client; I personally
would suggest, in order of preference

	i) to fix the buggy client, although I	suspect that this
	   is not an option in your case), or

	ii) to keep dnsmasq unmodified, keep it running in
	    dhcp-authoritative mode, and run an additional, standalone
	    daemon which would spy on the DHCP traffic, specifically
	    recognize the buggy client DHCPREQUEST frames and send a
	    crafted DHCPNAK on its own. This would never clash with
	    dnsmasq since only one of the two daemons would ever send
	    a DHCPNAK message. And if ever dnsmasq started sending
	    DHCPNAKs to your buggy client, you'd just have to remove
	    the custom daemon.

But as I wrote, the answer to your question is now in Simon's hands.

> Thanks

NP!

Amicalement,
-- 
Albert.