[Dnsmasq-discuss] Weird Routing/FW/dnsmasq problem
Simon Kelley
simon at thekelleys.org.uk
Sun Oct 30 21:57:51 GMT 2005
Dan Shechter wrote:
> Hi,
> This isn't really a dnsmasq problem, but a "routing" problem,
> I'm mailing this here hoping that someone overcame this before...
>
> I'm trying to get dnsmasq to respond with "DHCPNAK" commands while in
> dhcp-authorative mode.
>
> The "catch", so to speak, is that the clients are roaming in from
> different
> networks. And sometimes when they "come-in" to the dnsmasq managed
> network, they generate packets which are local broadcast packets from
> their old source ip address to 255.255.255.255.
>
> For example, clients generate DHCP REQUEST packets from:
> 10.100.4.134 -> 255.255.255.255
> while dnsmasq runs on a machine where the interface receiving the
> broadcast packet is configured as "192.168.101.200".
>
> I cannot seem to successfully make dnsmasq "respond" to these packets.
> dnsmasq remains sleeping (verified with strace) while these DHCP REQUEST
> packets are generated.
>
> I've attached two ethereal dump files, one is a plain packet dump, one
> is a
> Detailed one:
> The client try the same DHCP request 3 times (packets 418-420), and
> gives up after 40 seconds, doing a DHCP DISCOVER (packet 421) with
> source address "0.0.0.0" which succeeds.
>
> Any help will be GREATLY appreciated!
I strongly suspect that the DHCP REQUEST packets are being dropped by
iptables/firewall rules, before ever getting to dnsmasq. under these
conditions, dnsmasq would generate a DHCPNAK if it got the packet, and
your strace test shows fairly clearly that it isn't.
I'm no expert on iptables, but start by dumping the rules and looking
for rules which might drop UDP packets. iptables -L will do the trick.
Also consider adding logging to iptables to understand better what is
going on.
Cheers,
Simon.
More information about the Dnsmasq-discuss
mailing list