[Dnsmasq-discuss] Weird Routing/FW/dnsmasq problem

[Simon Kelley]

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.