Yes, I totally agree, although I know for a fact that these packets are
not dropped by iptables, since I've written an explicit rule to ACCEPT
them.
I've basically done a:
"iptables -t filter -A INPUT -p udp --dport 67 -s ! 192.168.100.0/24 -j
ACCEPT"
And I can verify using "iptables -L -n -v -t filter" that this rule in
the
FW chains is being hit upon using the packet counters.
My problem seems to be related more to routing.
A possible fix to this situation is for example to configure an
Additional device:
"ifconfig eth2:0 up 10.0.0.0 netmask 255.0.0.0"
This command alone, allows dnsmasq to "see" the packets and return a
broadcast NAK.
Shechter.
> -----Original Message-----
> From: Simon Kelley [mailto:si...@thekelleys.org.uk]
> Sent: Sunday, October 30, 2005 23:58
> To: Dan Shechter
> Cc: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] Weird Routing/FW/dnsmasq problem
>
> 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.
