Hi again Nikita, Le Fri, 20 Jan 2017 13:24:10 -0800 "Nikita N." <[email protected]> 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 [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
