[Dnsmasq-discuss] dnsmasq ignores DHCPDISCOVER

[Rainer Dorsch]

Am Sonntag, 30. Dezember 2007 schrieb Simon Kelley:
> Rainer Dorsch wrote:
> > Am Sonntag, 30. Dezember 2007 schrieben Sie:
> >
> >
> > Thanks for the quick reply. Which broadcasts do you think are dropped?
> > The incoming dhcpdiscover requests or the outgoing response?
>
> dhcpdiscover. If they were getting through, you would see them logged by
> dnsmasq. The responses are not (normally) broadcasts.
>
> > I use shorewall to configure the firewall on the nslu2 (running dnsmasq)
> > and it should not have any ports blocked to the local net and visa versa
> > (iptables output at the end of the mail):
> >
> >
> > #Basically defines loc (192.168.1.*) and net (internet)
> > rd at nslu2:~$ grep -E -v '^#' /etc/shorewall/interfaces
> > net     ppp0            detect
> > dhcp,tcpflags,norfc1918,routefilter,nosmurfs,logmartians
> > loc     eth0            detect          tcpflags,detectnets,nosmurfs
> > rd at nslu2:~$
> >
> > # Defines the firewall fw
> > rd at nslu2:~$ grep -E -v '^#' /etc/shorewall/zones
> > fw      firewall
> > net     ipv4
> > loc     ipv4
> > rd at nslu2:~$
> >
> > # does not block anything between FW and loc
> > rd at nslu2:~$ grep -E '(loc|all)' /etc/shorewall/policy|grep FW|grep -v -E
> > '^#' loc             $FW             ACCEPT
> > $FW             all             ACCEPT
> > rd at nslu2:~$
> >
> > The whole config translates into a lengthy set of iptables (which I am
> > not very familar to read directly):
> >
> > http://bokomoko.de/~rd/iptables.out
> >
> > Rainer
>
> I'm not a great firewall expert, and the raw iptables is very difficult
> to read, but there's a reference at the end of this:
> http://leaf.sourceforge.net/doc/buci-dnsmasq.html which looks like it
> might be the answer.

Thanks again for the quick reply. 

That rule does not solve my problem, but stopping shorewall makes the dhcp 
server in dnsmasq working.

Although I tried for a while, I do not understand at all, why shorewall drops 
the packet. I cannot even make shorewall logging the rejected or dropped 
broadcst packets (although it does so for packets coming from the internet).

When I log all packets, I see the broadcast (?) packets though:

Dec 31 00:27:22 nslu2 kernel: Shorewall:mangle:PREROUTING:IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:0d:60:79:f8:ba:08:00 SRC=0.0.0.0 DST=255.255.255.255 
LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Dec 31 00:27:22 nslu2 kernel: Shorewall:nat:PREROUTING:IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:0d:60:79:f8:ba:08:00 SRC=0.0.0.0 DST=255.255.255.255 
LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Dec 31 00:27:22 nslu2 kernel: Shorewall:mangle:INPUT:IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:0d:60:79:f8:ba:08:00 SRC=0.0.0.0 DST=255.255.255.255 
LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Dec 31 00:27:22 nslu2 kernel: Shorewall:filter:INPUT:IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:0d:60:79:f8:ba:08:00 SRC=0.0.0.0 DST=255.255.255.255 
LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308

Now I found the root cause:

loc     eth0            detect          tcpflags,nosmurfs,detectnets

needs to become

loc     eth0            detect          tcpflags,nosmurfs

From the description it does additional filtering and maybe filters out the 
SRC 0.0.0.0 (?):
#                       detectnets   - Automatically taylors the zone named
#                                      in the ZONE column to include only 
those
#                                      hosts routed through the interface.


Thanks,
Rainer

-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch at web.de
jabber: rdorsch at jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/