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.
