Description of problem: systemctl status show ip(6)tables.service are running ok systemctl shows shorewall is not running, but will start with command: systemctl start shorewall.service However, same for sw6 does not work. relevant journal entries are (excluding "Dec 08 08:59:36 localhost" for each line: systemd[1]: Starting Shorewall IPv6 firewall... shorewall6[4256]: Compiling... shorewall6[4256]: Processing /etc/shorewall6/params ... shorewall6[4256]: Processing /etc/shorewall6/shorewall6.conf... shorewall6[4256]: Loading Modules... kernel: xt_addrtype: ipv6 does not support BROADCAST matching kernel: xt_CT: No such helper "snmp" kernel: xt_CT: No such helper "pptp" kernel: xt_CT: No such helper "irc" kernel: xt_CT: No such helper "irc-0" kernel: xt_CT: No such helper "netbios-ns" shorewall6[4256]: Compiling /etc/shorewall6/zones... shorewall6[4256]: ERROR: No IP zones defined logger[4533]: ERROR:Shorewall6 start failed systemd[1]: shorewall6.service: main process exited, code=exited, status=255/n/a systemd[1]: Failed to start Shorewall IPv6 firewall. systemd[1]: Unit shorewall6.service entered failed state. But in Cauldron on the same machine with the same packages, sw6 starts and runs, so that (and below) proves that sw6 is not set up correctly. Comparing files in beta 2'e /etc/shorewall6 and current Cauldron's /etc/shorewall6 probably show where the problem lies, and hopefully how the package might be fixed: *beta2 file "interfaces" has ending line "net + detect" but "detect" is not described in man page *beta2 file "policy" has no lines that are not comments, my Cauldron file ends in: fw net ACCEPT net all DROP info all all REJECT info *beta 2 file "zones" ends in one effective reading: fw firewall but Cauldron's file "zones" ends in these lines: net ipv6 fw firewall I'm guessing that the install scripts need to be adapted at least for (some of) above. Reproducible: Steps to Reproduce:
Adding Thomas because of Live DVD (Gnome 64 bits) was used.
CC: (none) => tmbWhiteboard: (none) => 4beta2
Classical installer has same result and same set up of /etc/shorewall6 files. But journalctl output differs: journalctl |grep shorewall6: Dec 08 19:35:56 dvglt.homepower shorewall6[1676]: Compiling... Dec 08 19:35:57 dvglt.homepower shorewall6[1676]: Processing /etc/shorewall6/params ... Dec 08 19:35:57 dvglt.homepower shorewall6[1676]: Processing /etc/shorewall6/shorewall6.conf... Dec 08 19:35:57 dvglt.homepower shorewall6[1676]: Loading Modules... Dec 08 19:36:02 dvglt.homepower systemd[1]: shorewall6.service: main process exited, code=exited, status=255/n/a Dec 08 19:36:02 dvglt.homepower systemd[1]: Unit shorewall6.service entered failed state. Dec 08 19:36:03 dvglt.homepower shorewall6[1676]: ERROR: FORWARD_CLEAR_MARK=Yes requires MARK Target in your kernel and iptables journalctl |grep kernel, manually deleted anything that seems unrelated: Dec 08 19:35:47 dvglt.homepower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0f0: link becomes ready Dec 08 19:35:56 dvglt.homepower kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Dec 08 19:35:56 dvglt.homepower kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team Dec 08 19:35:57 dvglt.homepower kernel: Netfilter messages via NETLINK v0.30. Dec 08 19:35:58 dvglt.homepower kernel: xt_time: kernel timezone is -0000 Dec 08 19:35:58 dvglt.homepower kernel: ctnetlink v0.93: registering with nfnetlink. Dec 08 19:35:58 dvglt.homepower kernel: ip_set: protocol 6 Dec 08 19:35:59 dvglt.homepower kernel: ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully Dec 08 19:36:00 dvglt.homepower kernel: xt_addrtype: ipv6 does not support BROADCAST matching Dec 08 19:36:01 dvglt.homepower kernel: ipt_ULOG: ULOG is deprecated and it will be removed soon, use NFLOG instead Dec 08 19:36:02 dvglt.homepower kernel: xt_CT: No such helper "snmp" Dec 08 19:36:02 dvglt.homepower shorewall[1675]: ERROR: Log level INFO requires LOG Target in your kernel and iptables Dec 08 19:36:03 dvglt.homepower kernel: xt_CT: No such helper "pptp" Dec 08 19:36:03 dvglt.homepower systemd[1]: Startup finished in 8.742s (kernel) + 33.391s (userspace) = 42.134s. Dec 08 19:36:03 dvglt.homepower shorewall6[1676]: ERROR: FORWARD_CLEAR_MARK=Yes requires MARK Target in your kernel and iptables Dec 08 19:36:03 dvglt.homepower kernel: xt_CT: No such helper "irc" Dec 08 19:36:03 dvglt.homepower kernel: xt_CT: No such helper "irc-0" Dec 08 19:36:03 dvglt.homepower kernel: xt_CT: No such helper "netbios-ns" Dec 08 19:49:13 dvglt.homepower kernel: netfilter PSD loaded - (c) astaro AG Dec 08 19:49:13 dvglt.homepower kernel: IFWLOG: register target
Summary: M4B2 After install from Live disk shorewall6 cannot start => M4B2 After install shorewall6 cannot start
This seems related to / is ph duplicate of (to be reopened ?) bug #10947.
Valid for classical isos beta2 prerelease round 4. @bugsquad@mageia.org: should this not be a release blocker ph ?
Source RPM: shorewall-ipv6-4.5.20 => shorewall-ipv6-4.5.20-2
Priority: Normal => release_blockerCC: (none) => ennael1, mageia, thierry.vignaud
Blocks: (none) => 11704
Hi, thanks for reporting this bug. As there is no maintainer for this package I added the committers in CC. (Please set the status to 'assigned' if you are working on it)
Keywords: (none) => TriagedCC: (none) => alien, anssi.hannula, cooker, lmenut, mageia, n54, oe, pterjan
Still valid for 4RC. Roughly same results from journalctl Same differences in tails of files in /etc/shorewall6 as reported above.
Source RPM: shorewall-ipv6-4.5.20-2 => shorewall-ipv6-4.5.20-3Whiteboard: 4beta2 => 4RC
Comment 6 is for 64 bit iso (1st round classical dvd). With 32 bit iso, after 2nd reboot shorewall is running okay, but shorewall6 is not and cannot be started: files as per above.
Summary: M4B2 After install shorewall6 cannot start => M4RC After install shorewall6 cannot start
Created attachment 4731 [details] journalctl output on first boot service shorewall.service status showed an error (missing kernel support) It disappeared after restarting the service
Yeah, it does not wait long enough for network to be up... I wonder if the "net + detect" is screwing with us... I will remove it on next livecd build to test
@tmb re #c9 I'm afraid that won't be enough to make sw6 work: please see the differences between working sw6 and installed sw6 as per second half of my original description.
When upgrading from M3.1 to M4 one or both of sw / sw6 needs a restart. (In 64 bits upgrade it was sw6 only for me, in 32 bits upgrade it was both sw* for me). They work though, since they were configured to work okay under M3.
In addition to post install, I need to add that in Live mode the service shorewall and shorewall6 are not running and restart fails.
CC: (none) => eeeemail
The not waiting long enough for network-up is perhaps a wider issue. I'll have a poke at that bit. Certainly on an older install, the shorewall service started OK with a simple restart, but the shorewall6 one needed more configuring... will try with more recent builds.
@coling: I believe the package scripts are just incomplete: if these are finished (please compare remarks in 2nd half of the original report), s6 could easily be made to work out of the box, IMHO.
(In reply to Dick Gevers from comment #14) > @coling: I believe the package scripts are just incomplete: if these are > finished (please compare remarks in 2nd half of the original report), s6 > could easily be made to work out of the box, IMHO. Well I think there could be two issues. With the primary one, yes I think you're correct, but with the other I think it could be systemd or network-up related. e.g. on a test install here shorewall appears as failed on boot, but a simple restart kicks it into life. It *is* delayed by network-up.service, but perhaps not long enough. I'll poke into that bit of it (I've noticed a similar problem with network mounts not happening at boot a couple of times recently too which could be the same problem)
*** Bug 10979 has been marked as a duplicate of this bug. ***
CC: (none) => junk_no_spam
Comparing installs and upgrades, behaviour is inconsistent. In one case shorewall is running and *6 needs a restart, in another case it is the other way round. Also, when upgrading shorewall(6).conf are created, showing PATH is not written consistent with Mageia filsesystem: /bin and /sbin are included which are superfluous because they are symlinks to /usr/bin and /usr/sbin, which are also in PATH.
Whiteboard: 4RC => 4final
(In reply to Dick Gevers from comment #17) > Comparing installs and upgrades, behaviour is inconsistent. In one case > shorewall is running and *6 needs a restart, in another case it is the other > way round. I continue to find it this way also. Simply not allowing it to start at boot and rebooting for sure turns it all off.
CC: (none) => wilcal.int
Also for Live CDs after reboot, and during live sessions.
Summary: M4RC After install shorewall6 cannot start => M4final After install shorewall6 cannot start
*** Bug 9723 has been marked as a duplicate of this bug. ***
Regarding shorewall not starting, as reported earlier it seems that not enough time is given to load the kernel modules. This is why a simple restart of the service works fine. I've not specifically seen any fix for this in the release notes but upgrading shorewall to 4.5.21.5 has given me 20+ reboots without seeing this issue now. Previously I would get this issue on about 3 out of 10 boots. It could be due to starting two iptables instances at the same time (which could happen if both shorewall and shorewall6 are started in parallel) could lead to some issues previously[1], but apparently shorewall 4.21 has a fix for this. Can't say for sure this is the issue but either way it seems better for me. 1. http://shorewall.net/pub/shorewall/4.5/shorewall-4.5.21/releasenotes.txt 1) ip[6]tables 1.4.20 introduced an incompatible change that causes the program to fail if there is another instance of either iptables or ip6tables already running. This behavior can be avoided if the new -w option is specified. To work around this problem, the compiler now uses the -w option (when available) during capabilities determination so that shorewall and shorewall6 compilations can proceed in parallel.
commit 12c946b22963a7b5e7607d2e93c6ae0857f66795 Author: Colin Guthrie <colin@...> Date: Sat Jan 25 14:56:28 2014 +0000 shorewall: correct path to shorewall config mga#11928 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=12c946b22963a7b5e7607d2e93c6ae0857f66795
commit 4c4932684e34027cadc0fd111ff27487018dea73 Author: Colin Guthrie <colin@...> Date: Sat Jan 25 15:46:41 2014 +0000 shorewall: add minimal ipv6 support mga#11928 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=4c4932684e34027cadc0fd111ff27487018dea73
I've added minimal support for writing shorewall6 config files to drakx-net. The patches are on the topic/bug11928 branch here: http://gitweb.mageia.org/software/drakx-net/log/?h=topic/bug11928 I've not had time to test them but perhaps Thierry or Thomas can do this if they get a mo'? I should be able to test tomorrow. I *think* they will write an appropriate config files for both during install.
Sorry this new version is in Live disks round 3, but shorewall6 does not start: files in /etc/shorewall6 are not properly configured (systemctl gives ERROR: no ip zones defined). In original report is shown how I think the files should read.
Source RPM: shorewall-ipv6-4.5.20-3 => shorewall-ipv6-4.5.21-5
For completeness sake: my last comments are for the situation in Live mode, which is how far I am with the first disk I am testing. Yet to find how the system responds after completion of install.
@Dick, can you show the /etc/shorewall6/zones file? does it contain any zones, or ipv4 zones?
i put in 2 extra
i put in 2 extra commits wrt minimal ipv6 support on that branch. this might fix the zones/interfaces file.
@alien re #c27: As reported earlier, zones file ends with: fw firewall but IMHO this should be: net ipv6 fw firewall
After completing install it is the same as in Live mode.
Thanks for the additional fixes AL13N :) I actually realised about the ipv4 vs ipv6 string this morning when I woke up, so it was nice to see you'd already fixed it! I've now tested this change and the install went well and both shorewall and shorewall6 configs were written successfully. Think it's time to push this officially.
All pushed! I'll wait for someone else to close it but for me it's fixed now.
Thanks. I'm sure it's okay, but I'll close as soon as I'm able to verify it.
Fixed in last classical isos. Anybody to test it using live iso ?
@ennael1: sorry, no the latest packages are not in todays's iso'ss yet. It should now be fixed, but I haven't been able to verify that till now. Next iso's should have them.
After M3.1 -> M4 upgrade shorewall6 is now okay. However in /etc/shorewall/interfaces is now shown: net eth0 detect net enp5s0f0 detect net wlan0 detect which is wrong according to http://www.shorewall.net/manpages/shorewall-interfaces.html saying that the BROADCAST 'detect' variable can only be used if 'FORMAT 1' is given higher up, which it is not, but there is no FORMAT line. Also there is an interfaces.rpmnew reading: ?FORMAT 2 ... net + detect which makes it equally wrong. Next I will test with fresh install and report
I think with no FORMAT line it defaults to 1, so this is OK. IMO the .rpmnew file should have the format line removed as well as adding in the net+detect bit.
@coling > I think with no FORMAT line it defaults to 1, so this is OK. Sorry yes you are correct, as the docs. said 'deprecated' I overlooked that. > IMO the .rpmnew file should have the format line removed No, it did have the line "?FORMAT 2". Also in a fresh install the shorewall files are okay. But the shorewall6 files are not: The file 'interfaces' also has: ?FORMAT 2 ... net + detect and the file 'zones' only has the line: fw firewall so is missing the line: net ipv6 and the file 'policy' has no effective content which IMHO should be as above shown.
(In reply to Dick Gevers from comment #39) > > IMO the .rpmnew file should have the format line removed > > No, it did have the line "?FORMAT 2". Yeah, that's why I said "should". AFAICT (looking at the rpm itself) the lines remain and I am suggesting they should be removed if we have the detect line there by default. > Also in a fresh install the shorewall files are okay. This is because the drakx-net code fixes them up. > But the shorewall6 files are not: > > The file 'interfaces' also has: > ?FORMAT 2 > ... > net + detect > > > > and the file 'zones' > only has the line: > fw firewall Yes, but as Anne said above, this is all fixed now in drakx-net (I made these changes on Saturday) and a fresh install should now tidy up the shorewall6 files too. See the various referenced commits above. I tested this with a hacked up stage2. So in short, I think the only remaining issue is one in the spec file for shorewall itself where the ?FORMAT lines are not nuked. If this is correct, this simple change to the spec should be sufficient. Do you concur? Index: SPECS/shorewall.spec =================================================================== --- SPECS/shorewall.spec (revision 568410) +++ SPECS/shorewall.spec (working copy) @@ -228,8 +228,11 @@ # Don't install systemd service in /lib/systemd rm -f %{buildroot}/lib/systemd/system/shorewall.service -# (tmb) allow outgoing traffic on any interface by default (mga #10947) +# (tmb) allow outgoing traffic on any interface by default (mga#10947) +# (cg) drop the ?FORMAT 2 line as it disagrees with 'detect' (mga#11928) +perl -n -i -e 'print unless m!^?FORMAT 2$!' %{buildroot}%{_sysconfdir}/%{name}/interfaces echo "net + detect" >> %{buildroot}%{_sysconfdir}/%{name}/interfaces +perl -n -i -e 'print unless m!^?FORMAT 2$!' %{buildroot}%{_sysconfdir}/%{name6}/interfaces echo "net + detect" >> %{buildroot}%{_sysconfdir}/%{name6}/interfaces %post
@coling > Do you concur? It sounds quite logical what you say, but I do not have your abilities to say, for example, that the spec file change is okay: I regret that is beyond me.
(In reply to Colin Guthrie from comment #40) ... > > So in short, I think the only remaining issue is one in the spec file for > shorewall itself where the ?FORMAT lines are not nuked. AFAIK, "detect" is invalid in shorewall6/interfaces even in FORMAT 1. > > If this is correct, this simple change to the spec should be sufficient. > > Do you concur? > > Index: SPECS/shorewall.spec > =================================================================== > --- SPECS/shorewall.spec (revision 568410) > +++ SPECS/shorewall.spec (working copy) > @@ -228,8 +228,11 @@ > # Don't install systemd service in /lib/systemd > rm -f %{buildroot}/lib/systemd/system/shorewall.service > > -# (tmb) allow outgoing traffic on any interface by default (mga #10947) > +# (tmb) allow outgoing traffic on any interface by default (mga#10947) > +# (cg) drop the ?FORMAT 2 line as it disagrees with 'detect' (mga#11928) > +perl -n -i -e 'print unless m!^?FORMAT 2$!' > %{buildroot}%{_sysconfdir}/%{name}/interfaces > echo "net + detect" >> %{buildroot}%{_sysconfdir}/%{name}/interfaces > +perl -n -i -e 'print unless m!^?FORMAT 2$!' > %{buildroot}%{_sysconfdir}/%{name6}/interfaces > echo "net + detect" >> %{buildroot}%{_sysconfdir}/%{name6}/interfaces Be careful, config files have not always exactly the same syntax in shorewall and shorewall6. eg. in shorewall6/interfaces "detect" is invalid; in FORMAT 1, the ANYCAST column should have "-". http://www.shorewall.net/manpages6/shorewall6-interfaces.html "FORMAT 1 (default - deprecated) There is a ANYCAST column which provides compatibility with older versions of Shorewall.. [...] ANYCAST - - Enter '-' in this column. It is here for compatibility between Shorewall6 and Shorewall and is omitted if FORMAT is 2."
On my system here, using detect in shorewall6 configs seems to parse and behave fine, so it seems OK. We'd really appreciate any help from someone clued up here, but I think the configs are sufficient for release even if it could be better and shorewall6 support beefed up. Code can be found here: http://gitweb.mageia.org/software/drakx-net/tree/lib/network/shorewall.pm Patches more than welcome!
Wowking okay with this afternoon's new iso. Much obliged.
Status: NEW => RESOLVEDResolution: (none) => FIXED
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=15235