Hello, although this might be a "works as specified" issue, I though it is worth mentioning it here, I spend some time on it yesterday and did not find anything googling for the problem. I run a dnsmasq DHCP server and shorewall on a (low memory) nslu2 server. The dnsmasq DHCP server did not receive and dhcpdiscover broadcasts. Also I could not make shorewall logging the dropped or rejected dhcpdiscover packets by adding info attributes to the policies in the policy file. I could log the packets though after setting LOGALLNEW=debug This is the syslog entry: 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 The root cause in my config was the line loc eth0 detect tcpflags,nosmurfs,detectnets which had a detectnets. loc eth0 detect tcpflags,nosmurfs works well. The documentation says # detectnets - Automatically taylors the zone named # in the ZONE column to include only those # hosts routed through the interface. Seems that this also affected the broadcast packets (dhcpdiscover). Is removing the detectnets the recommended solution? If yes, it would have helped me, if it would have been mentioned in the documentation, it might be worth to add a few words in the doucmentation. Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdorsch@web.de jabber: rdorsch@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Rainer Dorsch wrote:> > loc eth0 detect tcpflags,nosmurfs,detectnets > > which had a detectnets. > > loc eth0 detect tcpflags,nosmurfs > > works well. > > The documentation says > > # detectnets - Automatically taylors the zone named > # in the ZONE column to include only those > # hosts routed through the interface. > > Seems that this also affected the broadcast packets (dhcpdiscover). Is > removing the detectnets the recommended solution?Yes. The ''detectnets'' option was a really bad idea and has been removed from Shorewall-perl. Consequently, if you ever migrate to Shorewall 4.0 with Shorewall-perl, you will have no choice but to delete the option anyway. The problem is not the broadcast address itself but the fact that DHCPDISCOVER packets have SOURCE IP address 0. That address won''t be in any detected zone. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> Rainer Dorsch wrote: >> >> Seems that this also affected the broadcast packets (dhcpdiscover). Is >> removing the detectnets the recommended solution? > > Yes. The ''detectnets'' option was a really bad idea and has been removed from > Shorewall-perl. Consequently, if you ever migrate to Shorewall 4.0 with > Shorewall-perl, you will have no choice but to delete the option anyway.Of course another thing you could have done would have been to add the ''dhcp'' option to the interface. You probably should do that anyway. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> # detectnets - Automatically taylors the zone namedThe spelling mistake indicates that this is quite an old version of shorewall - you appear to be using 2.x or earlier. Upgrading is highly advised; 2.x is broken in all kinds of interesting ways. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Am Montag, 31. Dezember 2007 schrieb Andrew Suffield:> > # detectnets - Automatically taylors the zone named > > The spelling mistake indicates that this is quite an old version of > shorewall - you appear to be using 2.x or earlier. Upgrading is highly > advised; 2.x is broken in all kinds of interesting ways.I am using 3.2.6 which shipped with the latest stable version of Debian 4.0r2 (aka etch): rd@nslu2:~$ dpkg -s shorewall|grep Version Version: 3.2.6-2 rd@nslu2:~$ I copied the spelling from the interfaces config file nslu2:~# grep detectnets /etc/shorewall/interfaces # detectnets - Automatically taylors the zone named # WARNING: DO NOT SET THE detectnets OPTION ON YOUR loc eth0 detect tcpflags,nosmurfs,dhcp,detectnets nslu2:~# and I added the dhcp option which works fine :-) Here are the diffs between the original shorewall package and what Debian ships: http://ftp.debian.org/debian/pool/main/s/shorewall/shorewall_3.2.6-2.diff.gz I did not find a diff in the detectnets area in the interfaces file though.... Thanks for your detailed responses. Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdorsch@web.de jabber: rdorsch@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Jan 01, 2008 at 12:08:14PM +0100, Rainer Dorsch wrote:> I am using 3.2.6Ah, that''s okay then. On further investigation, the original correction is svn revision 2332 ("spelling correction"), dated July 13 2005 and a few revisions before the version number updates to 3.0, but it does not appear in any released versions. Curiously, the manpage version copied the error, and then corrected it in the apparently unrelated revision 5940 "Make example match one-interface sample zone names", which first released in 3.4.3 (April 2007). Tom, any idea what''s going on there? This correction isn''t particularly important, but I''m wondering if any other changesets have been somehow lost. It smells like a botched merge. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:> On Tue, Jan 01, 2008 at 12:08:14PM +0100, Rainer Dorsch wrote: >> I am using 3.2.6 > > Ah, that''s okay then. > > > On further investigation, the original correction is svn revision 2332 > ("spelling correction"), dated July 13 2005 and a few revisions before > the version number updates to 3.0, but it does not appear in any > released versions. > > Curiously, the manpage version copied the error, and then corrected it > in the apparently unrelated revision 5940 "Make example match > one-interface sample zone names", which first released in 3.4.3 (April > 2007). > > Tom, any idea what''s going on there? This correction isn''t > particularly important, but I''m wondering if any other changesets have > been somehow lost. It smells like a botched merge.The change was somehow reversed by the next revision -- 2409. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/