Sorry I apologize, an important correction: the gateway_ip is also not
correct, also gateway_ip is most of times bugged:
-Internet Protocol Version 4, Src: 1.2.3.4 (1.2.3.4), Dst: 5.6.7.8
(wrong_gateway_ip)

But still those client DHCP frames pop up on the gateway/DHCP server
network, dnsmasq sees them allright.
Hope that helps to understand my (nasty) problem.
Thanks
-- 
  Nikita N.
  niki...@operamail.com


On Fri, Jan 20, 2017, at 01:24 PM, Nikita N. wrote:
> 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
> 

-- 
http://www.fastmail.com - Access all of your messages and folders
                          wherever you are


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

Reply via email to