For upstream after verification: shorewall-perl is not handling the "log_martians" option of its "interfaces" configuration file as described in man page (shorewall-interfaces(5)) and the release notes (/usr/share/doc/shorewall-<ver>/releasenotes.txt.bz2). Observed using release 4.09 (net-firewall/shorewall-perl-4.09-r1). In general, the perl-based compiler (unlike the shell-based compiler) is supposed to leave the user's /proc/sys settings alone, changing them by exception when an entry is present. For example, if the user does not specify "routefilter" at all in the "eth2" line in the "interfaces" file, then shorewall-perl does NOT alter /proc/sys/net/ipv4/conf/eth2/rp_filter. This same general principle is applied to the handling of the other similar options for configuring interfaces with shorewall-perl. There are minor exceptions where /proc/sys/net/ipv4 entries are modified based on global settings in /etc/shorewall/shorewall.conf or other configuration files, but I do not believe any such exceptions pertain to this "logmartians" case. Contrary to this general principle and the behavior described in the documentation specific to the configuration file's "logmartians" entry, the absence of said entry on any given interface appears to be taken as an indicator that shorewall-perl should disable log_martians on the interface. The simple workaround is to explicitly enable "logmartians=1" on interfaces as needed. Reproducible: Always Steps to Reproduce: 1. /etc/sysctl entries: net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.log_martians = 1 2. /etc/shorewall/interfaces entries: (No interface lines include "logmartians" 3. reboot 4. cat /proc/sys/net/ipv4/conf/*/log_martians Note that all are "0", and should be "1" 5. modify /etc/shorewall/interfaces (add "logmartians" to one or more interfaces) 6. reboot 7. cat /proc/sys/net/ipv4/conf/*/log_martians Note that one or more are now "1" 8. rc-update -d shorewall 9. reboot 10. cat /proc/sys/net/ipv4/conf/*/log_martians Note that all are now "1". Actual Results: If user does not have "log_martians" in /etc/shorewall/interfaces, then shorewall-perl changes /proc/sys/net/ipv4/conf/*/log_martians to "0". Expected Results: If user does not have "log_martians" in /etc/shorewall/interfaces, then shorewall-perl leaves /proc/sys/net/ipv4/conf/*/log_martians alone. Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r8 i686) ================================================================= System uname: 2.6.23-gentoo-r8 i686 Pentium II (Deschutes) Timestamp of tree: Thu, 28 Feb 2008 07:46:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.gtlib.gatech.edu/pub/gentoo http://open-systems.ufl.edu/mirrors/gentoo " LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1,--hash-style=gnu" LINGUAS="en_US en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 alsa bash-completion berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dri dvd dvdread encode fam firefox fortran gdbm gif gpm gstreamer gtk hal iconv imagemagick java jpeg logrotate mad midi mmx mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin nvidia ogg opengl pam pcre pdf perl png python quicktime readline reflection reiserfs samba sdl session spell spl ssl startup-notification svg symlink sysfs threads tiff truetype truetype-fonts type1-fonts unicode userlocales vorbis win32codecs x86 xml xorg xpm xv zlib" ALSA_CARDS="ens1371" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LINGUAS="en_US en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
CC'ing maintainer.
(In reply to comment #0) > shorewall-perl is not handling the "log_martians" option of its "interfaces" > configuration file as described in man page (shorewall-interfaces(5)) and the > release notes (/usr/share/doc/shorewall-<ver>/releasenotes.txt.bz2). Observed > using release 4.09 (net-firewall/shorewall-perl-4.09-r1). brendlerjg, have you reported this upstream? If not, then it would be great if you could subscribe to the Shorewall mailing list and post your findings there so that the developers can release a fix as this doesn't seem to be Gentoo-specific. Thanks
(In reply to comment #2) > have you reported this upstream? No, I expected we probably had a central point of contact for each application for passing such things upstream. It definitely does not seem to be a Gentoo problem. But I'll be happy to do so, provided nobody tells me this is bogus (I'm a new Shorewall user, so it's quite possible I just don't know what I'm talking about). :)
(In reply to comment #3) > No, I expected we probably had a central point of contact for each application > for passing such things upstream. It definitely does not seem to be a Gentoo > problem. You are partially correct. We are interested in bug reports even for upstream issues but maintainer can ask you to report bug upstream too. There is no duplication: we have this error in our distribution - so we have the bug, but maintainer is not a package developer and is not capable to fix all the problems for all the packages he/she maintains, so we ask upstream for help either by ourselves or ask our users to spend a little bit more time and report bug upstream too. General and the best way to proceed with such bugs is to report them both here and upstream. After that add the URL to upstream bug report inside URL field and keep this bug open until it is fixed in portage tree. This way helps us to be aware about bugs in software we maintain and really in some case could be good starting point to find help and to check that the behavior you experience is actually bug and not misconfiguration on your side or similar. More importantly, this way allows us to propagate fixes in our tree without waiting for next upstream release (consider kde/gnome releases which are scheduled...). So yes, please, report bugs in our bugzilla and keep them open until they are fixed. But, please, to help us even more it's better if you report bug you experience upstream too: sometimes it's hard to reproduce your problem for us, sometimes maintainer is a bit busy so he/she asks you to go ahead and contact upstream yourself and finally you'll better answer additional questions from upstream ;) At the end we are community distribution so we live with help from our users. > But I'll be happy to do so, provided nobody tells me this is bogus (I'm a new > Shorewall user, so it's quite possible I just don't know what I'm talking > about). :) Sorry I do not use shorewall-perl so I didn't tried to reproduce/check that this is really a problem but reading your explanation it seems like that. Bottom line: the best way to proceed (and help us to maintain packages) is to report bug here and upstream and add URL to official bug report here and keep this bug open until it is fixed in our tree. So once you'll report upstream, consider filling URL here and reopening this bug. HTH
Okay, thanks for the feedback. I joined the shorewall-users mailing list and reported it earlier this afternoon.
In "man shorewall.conf" there's a note on logmartians: LOG_MARTIANS=[Yes|No|Keep] If set to Yes or yes, sets /proc/sys/net/ipv4/conf/all/log_mar- tians and /proc/sys/net/ipv4/conf/default/log_martians to 1. De- fault is No which sets both of the above to zero. If you do not enable martian logging for all interfaces, you may still enable it for individual interfaces using the logmartians interface op- tion in shorewall-interfaces <shorewall-interfaces.html> (5). The value Keep is only allowed under Shorewall-perl. It causes Shorewall to ignore the option. If the option is set to Yes, then martians are logged on all interfaces. If the option is set to No, then martian logging is disabled on all interfaces except those specified in shorewall-interfaces <shorewall-interfaces.html> (5). If the behavior is not as described here then I'm sure that the Shorewall developers will be glad to investigate your report.
That was exactly the problem. I had overlooked setting: LOG_MARTIANS=Keep This produces the expected behavior. Thank you, and I apologize for the unnecessary report.
