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. niki...@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." <niki...@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... _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss