[Dnsmasq-discuss] dnsmasq always answer dhcp NAK
nikitan at operamail.com
Sat Jan 21 07:37:43 GMT 2017
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:
Unfortunately my bugged client has IP Src bugged, and IP Dst gateway
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
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
Is that possible?
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: 188.8.131.52 (184.108.40.206), 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: 220.127.116.11 (18.104.22.168)
> > --Your (client) IP address: 22.214.171.124 (126.96.36.199)
> > --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 188.8.131.52 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:184.108.40.206 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
http://www.fastmail.com - mmm... Fastmail...
More information about the Dnsmasq-discuss