[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.
  nikitan at 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." <nikitan at operamail.com> 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...