Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If I've understood the problem correctly, dnsmasq is never even seeing
these packets. If the destination address in the IP-level header is
for a random IP address then the kernel network stack will discard the
packet, even if the link-layer MAC address is correct so that the
packet arrives at the network hardware.

Since dnsmasq is listening at the IP level, and doesn't do raw packet
capture, it won't ever see the packets. Note that other DHCP servers
are available (such as ISC dhcpd) which do work at raw packet level.
I'm not sure if dhcpd would behave as you wish in this case, but it
would certainly be simpler to modify it to do so. Unless dnsmasq is
completely re-written to do raw packet capture (which it won't be)
there is not way to modify it to do what you want.


Cheers,

Simon.



On 21/01/17 07:37, Nikita N. wrote:
> 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. 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 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? 
> Thanks
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhfNUAAoJEBXN2mrhkTWik3kP/jeqWsbPY0TCXvgpSORy3aPG
WjU99BQsDth+EJDFrDwNlhqlq8iLrMRGHnyK8BCLcu9d7kqHuqPJrECIdzs8pyVx
J7qoux6lJI/hqWrQihFLaZbxPl4XkAxPBw+zZDecjBA5m4JzSfX4Zutq9jgjiVAJ
EMgPFgc/RZbm7eiid2Mrd5FhOei7aH//S99p7EQjSk+X6eNiHdpnvXfaNQjeQRQ/
2JSMcI3hkjc3GJgcD7a/NIfLYpMFeW48RZ7eUyFYm3FAx1PbBKf1OaqeO0eCjZ4u
C2CwjWRX+qefdQtQ/GzyYtHWCUX5sIrNCwKO6+zwhn74Yjm48TKV7IKtK/ypGCGH
2eqsYo32W1fa5e4QaG7IzcmV0uew20MgcKWjjKYBxr3K8edp4t55c4bS1gwLS1ou
9b5KK6s6uUvM0IcMxP6y71JPlvkndDwRjRqaeFdxD+Lr6HL5Faxw20eBOv/C9PNe
nzfJVZQ2+ReEHMThKakmXrEICbv3yNY2axnTg7an4fuheLDVNY5+9SENUb+PAOwt
o/ACsW2ue/2ufgGJjmoW5mU+3/e/TlKi1v8MqUcxeCoC7JeeD/qk5oySDgNXaZZp
X5FZWj/Nb+7qBSJtoWre8v9J3g70oKNTFyQ5x6m/9B5h5lBCK5skkpS3LXWr6IJ8
/89setpR61Nh7zD+bA0v
=qGI/
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Nikita N.]

Hi,
argh, embedded system, no space for python, nor Im able to develop
libpcap...

I still hope (cross fingers) dnsmasq can handle this somehow...

For Simon: we tested, dnsmasq is already handling smtng like this
(client correctly routed to different network) and it rightly sends DHCP
NAK+Option Message="wrong network".
*BUT ONLY* when the frames comes with 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).
When Dst mac is not Bcast and/or Src/Dst ip is not Bcast, then dnsmasq
just keeps silent... instead we would like dnsmasq answers NAK.
Hope that clarifies, thanks
-- 
  Nikita N.
  niki...@operamail.com


On Sat, Jan 21, 2017, at 12:37 AM, Albert ARIBAUD wrote:
> Hi again Nikita,
> 
> Le Sat, 21 Jan 2017 00:19:02 -0800
> "Nikita N."  a écrit:
> 
> > Hi,
> > 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 network.
> > 
> > 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 course)?
> > Or an easy net tool to easily forge fake UDP frames you can suggest?
> > Thanks
> 
> I assume you mean you don't want to actually code such a daemon in a
> compilable language such as C, and are instead looking for something to
> just install and configure without too much hassle?
> 
> Then there is scapy, a Python swiss-army-knife network application. Its
> the man page says it can replace "hping, parts of nmap, arpspoof,
> arp-sk, arping, tcpdump, tshark, p0f, ..."
> 
> See http://www.secdev.org/projects/scapy/demo.html for an introduction.
> It shows interactive uses, but this being Python, scapy is scriptable.
> It is also testable: you can feed it a pcap file and have it output to
> a pcap file too. It knows DHCP at least to some point.
> 
> You should quite probably be able to write a script that recognizes
> DHCP REQUESTs with mismatching IP layer and DHCP layer IPv4 addresses,
> and craft the corresponding DHCP NAKs.
> 
> If, however, resources are scarce (e.g., in an embedded product), then
> maybe you would be better off developing a C language daemon (possibly
> based on libpcap if this library is already present on the DHCP server
> marchine).
> 
> Amicalement,
> -- 
> Albert.

-- 
http://www.fastmail.com - A fast, anti-spam email service.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Albert ARIBAUD]

Hi again Nikita,

Le Sat, 21 Jan 2017 00:19:02 -0800
"Nikita N."  a écrit:

> Hi,
> 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 network.
> 
> 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 course)?
> Or an easy net tool to easily forge fake UDP frames you can suggest?
> Thanks

I assume you mean you don't want to actually code such a daemon in a
compilable language such as C, and are instead looking for something to
just install and configure without too much hassle?

Then there is scapy, a Python swiss-army-knife network application. Its
the man page says it can replace "hping, parts of nmap, arpspoof,
arp-sk, arping, tcpdump, tshark, p0f, ..."

See http://www.secdev.org/projects/scapy/demo.html for an introduction.
It shows interactive uses, but this being Python, scapy is scriptable.
It is also testable: you can feed it a pcap file and have it output to
a pcap file too. It knows DHCP at least to some point.

You should quite probably be able to write a script that recognizes
DHCP REQUESTs with mismatching IP layer and DHCP layer IPv4 addresses,
and craft the corresponding DHCP NAKs.

If, however, resources are scarce (e.g., in an embedded product), then
maybe you would be better off developing a C language daemon (possibly
based on libpcap if this library is already present on the DHCP server
marchine).

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Nikita N.]

Hi,
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
network.

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
course)?
Or an easy net tool to easily forge fake UDP frames you can suggest?
Thanks

-- 
  Nikita N.
  niki...@operamail.com


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."  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.

-- 
http://www.fastmail.com - Email service worth paying for. Try it for free


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Nikita N.]

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.
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 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?
Thanks
-- 
  Nikita N.
  niki...@operamail.com


On Fri, Jan 20, 2017, at 02:55 PM, Albert ARIBAUD wrote:
> Hi again Nikita,
> 
> Le Fri, 20 Jan 2017 13:24:10 -0800
> "Nikita N."  a écrit:
> 
> > Hi Albert,
> > thank you for your answer, but my config already has
> > --dhcp-authoritative.
> 
> OK, then. Have you tested that it does indeed work? (and you have also
> tested that the normal/correct DHCP leasing scenario indeed works?
> 
> > I will try to explain the problem in more details, showing the
> > Wireshark-style "bugged" frame, popping up on the wire:
> > -Ethernet II, Src: correct_mac_aa:bb:cc (mac_client), Dst:
> > correct_gateway_dd:ee:ff (mac_gateway)
> > -Internet Protocol Version 4, Src: 1.2.3.4 (1.2.3.4), Dst: 10.0.0.1
> > (correct_gateway_ip)
> > -User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
> > -Bootstrap Protocol (Request)
> > --Client IP address: 1.2.3.4 (1.2.3.4)
> > --Your (client) IP address: 1.2.3.4 (1.2.3.4)
> > --Client MAC address: correct_mac_aa:bb:cc (mac_client)
> > --Option: (53) DHCP Message Type (Request)
> > --Option: (61) Client identifier
> > --Option: (60) Vendor class identifier
> > --Option: (55) Parameter Request List
> > ---Parameter Request List Item: (1) Subnet Mask
> > ---Parameter Request List Item: (121) Classless Static Route
> > ---Parameter Request List Item: (33) Static Route
> > ---Parameter Request List Item: (3) Router
> > ---Parameter Request List Item: (6) Domain Name Server
> > ---Parameter Request List Item: (15) Domain Name
> > ---Parameter Request List Item: (28) Broadcast Address
> > ---Parameter Request List Item: (51) IP Address Lease Time
> > ---Parameter Request List Item: (58) Renewal Time Value
> > ---Parameter Request List Item: (59) Rebinding Time Value
> > ---Parameter Request List Item: (119) Domain Search
> > --Option: (255) End
> > 
> > The mac correct_mac is the correct mac of the bugged client, that is
> > always correct.
> > The ip 1.2.3.4 is the bug, this value changes randomly time by time
> > (no workaround), it can be anything: but luckily is coherent (same)
> > in the relevant positions of the single DHCP frame.
> 
> And it always matches the IP layer address? Because if it does, then
> the frame is valid; that is what a machine moved from one subnet to
> another might do, and a DHCP server (dnsmasq or other) is designed to
> handle this.
> 
> > Finally, as you notice, the relevant "Option: (50) Requested IP
> > Address" is always missing.
> 
> IIUC option 50 is not required, so I don't think its absence causes
> dnsmasq to skip answering this.
> 
> > What I need is: dnsmasq sends a DHCP Answer NAK with
> > Dst:correct_mac_aa:bb:cc (and possibly also ip Dst:1.2.3.4 whatever)
> > How can I set this?
> 
> That's what --dhcp-authoritative is about. Hence my suggestion to
> test with a working client that the server is indeed running in
> authoritative mode.
> 
> > Thanks
> 
> Amicalement,
> -- 
> Albert.

-- 
http://www.fastmail.com - mmm... Fastmail...


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Albert ARIBAUD]

Hi again Nikita,

Le Fri, 20 Jan 2017 13:24:10 -0800
"Nikita N."  a écrit:

> Hi Albert,
> thank you for your answer, but my config already has
> --dhcp-authoritative.

OK, then. Have you tested that it does indeed work? (and you have also
tested that the normal/correct DHCP leasing scenario indeed works?

> I will try to explain the problem in more details, showing the
> Wireshark-style "bugged" frame, popping up on the wire:
> -Ethernet II, Src: correct_mac_aa:bb:cc (mac_client), Dst:
> correct_gateway_dd:ee:ff (mac_gateway)
> -Internet Protocol Version 4, Src: 1.2.3.4 (1.2.3.4), Dst: 10.0.0.1
> (correct_gateway_ip)
> -User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
> -Bootstrap Protocol (Request)
> --Client IP address: 1.2.3.4 (1.2.3.4)
> --Your (client) IP address: 1.2.3.4 (1.2.3.4)
> --Client MAC address: correct_mac_aa:bb:cc (mac_client)
> --Option: (53) DHCP Message Type (Request)
> --Option: (61) Client identifier
> --Option: (60) Vendor class identifier
> --Option: (55) Parameter Request List
> ---Parameter Request List Item: (1) Subnet Mask
> ---Parameter Request List Item: (121) Classless Static Route
> ---Parameter Request List Item: (33) Static Route
> ---Parameter Request List Item: (3) Router
> ---Parameter Request List Item: (6) Domain Name Server
> ---Parameter Request List Item: (15) Domain Name
> ---Parameter Request List Item: (28) Broadcast Address
> ---Parameter Request List Item: (51) IP Address Lease Time
> ---Parameter Request List Item: (58) Renewal Time Value
> ---Parameter Request List Item: (59) Rebinding Time Value
> ---Parameter Request List Item: (119) Domain Search
> --Option: (255) End
> 
> The mac correct_mac is the correct mac of the bugged client, that is
> always correct.
> The ip 1.2.3.4 is the bug, this value changes randomly time by time
> (no workaround), it can be anything: but luckily is coherent (same)
> in the relevant positions of the single DHCP frame.

And it always matches the IP layer address? Because if it does, then
the frame is valid; that is what a machine moved from one subnet to
another might do, and a DHCP server (dnsmasq or other) is designed to
handle this.

> Finally, as you notice, the relevant "Option: (50) Requested IP
> Address" is always missing.

IIUC option 50 is not required, so I don't think its absence causes
dnsmasq to skip answering this.

> What I need is: dnsmasq sends a DHCP Answer NAK with
> Dst:correct_mac_aa:bb:cc (and possibly also ip Dst:1.2.3.4 whatever)
> How can I set this?

That's what --dhcp-authoritative is about. Hence my suggestion to
test with a working client that the server is indeed running in
authoritative mode.

> Thanks

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Nikita N.]

Hi Albert,
thank you for your answer, but my config already has
--dhcp-authoritative.
I will try to explain the problem in more details, showing the
Wireshark-style "bugged" frame, popping up on the wire:
-Ethernet II, Src: correct_mac_aa:bb:cc (mac_client), Dst:
correct_gateway_dd:ee:ff (mac_gateway)
-Internet Protocol Version 4, Src: 1.2.3.4 (1.2.3.4), Dst: 10.0.0.1
(correct_gateway_ip)
-User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
-Bootstrap Protocol (Request)
--Client IP address: 1.2.3.4 (1.2.3.4)
--Your (client) IP address: 1.2.3.4 (1.2.3.4)
--Client MAC address: correct_mac_aa:bb:cc (mac_client)
--Option: (53) DHCP Message Type (Request)
--Option: (61) Client identifier
--Option: (60) Vendor class identifier
--Option: (55) Parameter Request List
---Parameter Request List Item: (1) Subnet Mask
---Parameter Request List Item: (121) Classless Static Route
---Parameter Request List Item: (33) Static Route
---Parameter Request List Item: (3) Router
---Parameter Request List Item: (6) Domain Name Server
---Parameter Request List Item: (15) Domain Name
---Parameter Request List Item: (28) Broadcast Address
---Parameter Request List Item: (51) IP Address Lease Time
---Parameter Request List Item: (58) Renewal Time Value
---Parameter Request List Item: (59) Rebinding Time Value
---Parameter Request List Item: (119) Domain Search
--Option: (255) End

The mac correct_mac is the correct mac of the bugged client, that is
always correct.
The ip 1.2.3.4 is the bug, this value changes randomly time by time (no
workaround), it can be anything: but luckily is coherent (same) in the
relevant positions of the single DHCP frame.
Finally, as you notice, the relevant "Option: (50) Requested IP Address"
is always missing.

What I need is: dnsmasq sends a DHCP Answer NAK with
Dst:correct_mac_aa:bb:cc (and possibly also ip Dst:1.2.3.4 whatever)

How can I set this?
Thanks
-- 
  Nikita N.
  niki...@operamail.com


On Fri, Jan 20, 2017, at 12:25 PM, Albert ARIBAUD wrote:
> Le Fri, 20 Jan 2017 11:20:17 -0800
> "Nikita N."  a écrit:
> 
> > Hi,
> > I would like to know what is the setting, to force dnsmasq to *ALWAYS*
> > answer every wrong/bugged DHCP Request, with a standard DHCP NAK.
> > I have a bugged client which randomly (bugged driver) sends DHCP
> > Requests with a wrong/bugged IP, dnsmasq default behavior is not to
> > answer nothing: unfortunately when that happens the client hangs
> > forever waiting for the DHCP answer (only workaround is reboot).
> > Now, I want to force dnsmasq to answer NAK to every wrong/bugged DHCP
> > request incoming (instead of keeping silent).
> > Thanks.
> 
> Hi Nikita,
> 
> As per 'man dnsmasq', what you want is probably --dhcp-authoritative.
> The man page says this about it:
> 
>   Should be set when dnsmasq is definitely the only DHCP server
>   on a network.  For DHCPv4, it changes the behaviour from strict
>   RFC compliance so that DHCP requests on unknown leases from
>   unknown hosts  are  not  ignored.  This  allows new hosts to
>   get a lease without a tedious  timeout  under all
>   circumstances.  It  also allows dnsmasq to rebuild its lease
>   database without each client needing to reacquire a lease,  if
>   the  database is  lost.  For DHCPv6  it  sets  the  priority in
>   replies to 255 (the maximum) instead of 0 (the minimum).
> 
> Note however that this will do what you want or not, depending on what
> you mean by 'bugged'. If you mean "a request that could be legitimate
> in some circumstances but is not valid here", then --dhcp-authoritative
> will do the job. If you mean "a request which may have been randomly
> damaged" then there's no way dnsmasq will catch all these.
> 
> Amicalement,
> -- 
> Albert.

-- 
http://www.fastmail.com - The way an email service should be


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Albert ARIBAUD]

Le Fri, 20 Jan 2017 11:20:17 -0800
"Nikita N."  a écrit:

> Hi,
> I would like to know what is the setting, to force dnsmasq to *ALWAYS*
> answer every wrong/bugged DHCP Request, with a standard DHCP NAK.
> I have a bugged client which randomly (bugged driver) sends DHCP
> Requests with a wrong/bugged IP, dnsmasq default behavior is not to
> answer nothing: unfortunately when that happens the client hangs
> forever waiting for the DHCP answer (only workaround is reboot).
> Now, I want to force dnsmasq to answer NAK to every wrong/bugged DHCP
> request incoming (instead of keeping silent).
> Thanks.

Hi Nikita,

As per 'man dnsmasq', what you want is probably --dhcp-authoritative.
The man page says this about it:

Should be set when dnsmasq is definitely the only DHCP server
on a network.  For DHCPv4, it changes the behaviour from strict
RFC compliance so that DHCP requests on unknown leases from
unknown hosts  are  not  ignored.  This  allows new hosts to
get a lease without a tedious  timeout  under all
circumstances.  It  also allows dnsmasq to rebuild its lease
database without each client needing to reacquire a lease,  if
the  database is  lost.  For DHCPv6  it  sets  the  priority in
replies to 255 (the maximum) instead of 0 (the minimum).

Note however that this will do what you want or not, depending on what
you mean by 'bugged'. If you mean "a request that could be legitimate
in some circumstances but is not valid here", then --dhcp-authoritative
will do the job. If you mean "a request which may have been randomly
damaged" then there's no way dnsmasq will catch all these.

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss