Sorry, I wasn't clear.

A DHCP client can set a bit in the DHCP DISCOVER message that asks the
DHCP server to broadcast the reply to it. The packet captures you posted
showed exactly that. It's quite possible that the ThinkPad X260,
_doesn't_ do this, so the reply is not broadcast.

A source of problems in the past has been firewall (iptables) rules that
block packets sent to the broadcast address. Such a rule
on the machine running dnsmasq would  break DHCP but only for clients
which set the broadcast bit in the DHCPDISCOVER. I don't know if the
packet capture happens before or after iptables, for the packet to be
blocked, but still appear (as it did) in the packet capture, it would
have to be before iptables.



On 04/04/2019 18:42, Conrad Kostecki wrote:
> Hi Simon,
> Am 04.04.2019 16:10:32, "Simon Kelley" <> schrieb:
>> How are you producing the dnsmasq captures? on the host running dnsmasq,
>> or elsewhere on the network?
> Both captures were produced on that machine, which runs the DHCP server.
> This means, on the non working setup, this is my linux router.
> The fritzbox also does offer a capture on its interfaces itself.
> Captures where done with tcpdump on port 67+68.
>> The DHCP is asking for, and getting, broadcast replies (ie to
>> It's just possible that : 1) no other DHCP clients
>> you've used ask for this
> What do you mean by this? Sorry, but I didn't understand this.
>>  2) the firewall configuration on the host
>> running dnsmasq blocks packets with destination
> I can rule this out. If I take the same network cable, which I used for
> Netboot, but instead, connect my modern ThinkPad X260, DHCP works just
> perfectly fine.
> I did also give now a try and connected directly the Netboot machine to
> an interface directly on the machine, which hosts DNSMasq.
> So I think, I can rule out at least the hardware side here.
> Conrad
> _______________________________________________
> Dnsmasq-discuss mailing list

Dnsmasq-discuss mailing list

Reply via email to