yes indeed, we are facing some kind of "stochastic bug", which happens
randomly, otherwise that client network driver works usually fine.
Also yes, that network card is not produced anymore,nor there is any bug
support from the producer.
Anyway, too bad dnsmasq cant handle this.
I was infact hoping dnsmasq would handle this too, because it is very
similar to the cases when a client changes network (routed correctly,no
bug) when dnsmasq already answers such cases with a NAK+Message=wrong
Otherwise, the last resource I have (beside reboot) is forging a fake
DHCP NAK with some hacker net tool... it feels awful even just typing
isn it... :P
Albert thanks, do you know of such specific alternate "standalone daemon
which would spy on the DHCP traffic" you can suggest me (under linux of
Or an easy net tool to easily forge fake UDP frames you can suggest?
On Fri, Jan 20, 2017, at 11:58 PM, Albert ARIBAUD wrote:
> Hi again Nikita,
> Le Fri, 20 Jan 2017 23:37:43 -0800
> "Nikita N." <niki...@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
http://www.fastmail.com - Email service worth paying for. Try it for free
Dnsmasq-discuss mailing list