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.
