[Dnsmasq-discuss] Weird Routing/FW/dnsmasq problem
Simon Kelley
simon at thekelleys.org.uk
Mon Oct 31 14:04:38 GMT 2005
Dan Shechter wrote:
> 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.
Ok, that rules out iptables. Sorry to doubt you, but most problems of
this type which I see are iptables related.
>
> 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.
>
So it looks like there might be some code in the kernel that checks that
the source address is on a local network. That would make some sense:
packets sent to 255.255.255.255 are not meant to be routed, but if they
are it can cause mischief.
I had a quick poke around in the linux IP stack, but I couldn't see
anything obvious, and it's code which has been optimised for years by
very bright people, ie not very easy to understand.
BTW, what client are you using? I think most clients always set the
source address to zero when broadcasting. RFC2131 says
"DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0."
but that's ambiguous, since it's not clear if a client in INIT-REBOOT
state is "prior" to "obtaining its IP address".
Cheers,
Simon.
More information about the Dnsmasq-discuss
mailing list