[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