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." <niki...@operamail.com> 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

Reply via email to