Description of problem: When you connect to a WiFi network with a long SSID (>=15 Characters) and then configure your firewall it adds a loc entry to /etc/shorewall/interfaces that is too long for shorewall to handle. It will break shorewall, but drakfirewall will still claim everything is OK :-( Version-Release number of selected component (if applicable): Probably every version since drakfirewall was created? I'm calling it a major/critical issue since drakfirewall doesn't even let the user know his firewall is now down.
(In reply to comment #0) > I'm calling it a major/critical issue since drakfirewall doesn't even let the > user know his firewall is now down. I can agree that a status of shorewall should be returned since the default is no firewall. That is a poor decision in my opinion because of all the services that are running, not to mention systemd starting services it updates even though you have stopped them.
CC: (none) => junk_no_spam
Assignee: bugsquad => mageia
*** Bug 9015 has been marked as a duplicate of this bug. ***
CC: (none) => dag
Has this been resolved? 2 years since last comment.
CC: (none) => nic
looks I can reproduce, and so shorewall don't want to start :( févr. 28 00:16:09 linux drakfirewall[16709]: running: /bin/mountpoint -q /sys/fs/cgroup/systemd févr. 28 00:16:09 linux drakfirewall[16709]: running: /bin/systemctl --quiet is-active mandi.service févr. 28 00:16:09 linux drakfirewall[16709]: launched command: killall -s SIGUSR1 net_applet févr. 28 00:16:09 linux drakfirewall[16709]: ### Program is exiting ### févr. 28 00:16:09 linux shorewall[16995]: Compiling... févr. 28 00:16:09 linux shorewall[16995]: Processing /etc/shorewall/params ... févr. 28 00:16:09 linux shorewall[16995]: Processing /etc/shorewall/shorewall.conf... févr. 28 00:16:09 linux shorewall[16995]: Loading Modules... févr. 28 00:16:09 linux shorewall[16995]: Compiling /etc/shorewall/zones... févr. 28 00:16:09 linux shorewall[16995]: Compiling /etc/shorewall/interfaces... févr. 28 00:16:10 linux shorewall[16995]: Determining Hosts in Zones... févr. 28 00:16:10 linux shorewall[16995]: Locating Action Files... févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/policy... févr. 28 00:16:10 linux shorewall[16995]: Running /etc/shorewall/initdone... févr. 28 00:16:10 linux shorewall[16995]: Compiling TCP Flags filtering... févr. 28 00:16:10 linux shorewall[16995]: Compiling Kernel Route Filtering... févr. 28 00:16:10 linux shorewall[16995]: Compiling Martian Logging... févr. 28 00:16:10 linux shorewall[16995]: Compiling MAC Filtration -- Phase 1... févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/policy... févr. 28 00:16:10 linux shorewall[16995]: Running /etc/shorewall/initdone... févr. 28 00:16:10 linux shorewall[16995]: Compiling TCP Flags filtering... févr. 28 00:16:10 linux shorewall[16995]: Compiling Kernel Route Filtering... févr. 28 00:16:10 linux shorewall[16995]: Compiling Martian Logging... févr. 28 00:16:10 linux shorewall[16995]: Compiling MAC Filtration -- Phase 1... févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/rules... févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/conntrack... févr. 28 00:16:10 linux shorewall[16995]: Compiling MAC Filtration -- Phase 2... févr. 28 00:16:10 linux shorewall[16995]: Applying Policies... févr. 28 00:16:10 linux shorewall[16995]: Compiling /usr/share/shorewall/action.Drop for chain Drop... févr. 28 00:16:10 linux shorewall[16995]: Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast... févr. 28 00:16:10 linux shorewall[16995]: Generating Rule Matrix... févr. 28 00:16:10 linux shorewall[16995]: Compiling /usr/share/shorewall/action.Reject for chain Reject... févr. 28 00:16:10 linux shorewall[16995]: Creating iptables-restore input... févr. 28 00:16:10 linux shorewall[16995]: Shorewall configuration compiled to /var/lib/shorewall/.start févr. 28 00:16:10 linux shorewall[16995]: Starting Shorewall.... févr. 28 00:16:10 linux shorewall[16995]: Initializing... févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/init ... févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/tcclear ... févr. 28 00:16:10 linux shorewall[16995]: Setting up Route Filtering... févr. 28 00:16:10 linux shorewall[16995]: Setting up Martian Logging... févr. 28 00:16:10 linux shorewall[16995]: Setting up Proxy ARP... févr. 28 00:16:10 linux shorewall[16995]: Preparing iptables-restore input... févr. 28 00:16:10 linux shorewall[16995]: Running /sbin/iptables-restore... févr. 28 00:16:10 linux shorewall[16995]: iptables-restore v1.4.21: interface name `Auto_freebox_WDURIO' must be shorter than IFNAMSIZ (15) févr. 28 00:16:10 linux shorewall[16995]: Error occurred at line: 88 févr. 28 00:16:10 linux shorewall[16995]: Try `iptables-restore -h' or 'iptables-restore --help' for more information. févr. 28 00:16:10 linux shorewall[16995]: ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input févr. 28 00:16:10 linux logger[17228]: ERROR:Shorewall start failed févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/stop ... févr. 28 00:16:10 linux shorewall[16995]: iptables v1.4.21: Couldn't load target `Ifw':No such file or directory févr. 28 00:16:10 linux shorewall[16995]: Try `iptables -h' or 'iptables --help' for more information. févr. 28 00:16:10 linux shorewall[16995]: iptables: No chain/target/match by that name. févr. 28 00:16:10 linux shorewall[16995]: iptables: No chain/target/match by that name. févr. 28 00:16:10 linux shorewall[16995]: ipset v6.24: The set with the given name does not exist févr. 28 00:16:10 linux shorewall[16995]: ipset v6.24: The set with the given name does not exist févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/tcclear ... févr. 28 00:16:10 linux shorewall[16995]: Running /sbin/iptables-restore... févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/stopped ... févr. 28 00:16:10 linux logger[17255]: Shorewall Stopped févr. 28 00:16:10 linux shorewall[16995]: /usr/share/shorewall/lib.common : ligne 113 : 17183 Complété $SHOREWALL_SHELL $script $options $@ févr. 28 00:16:10 linux systemd[1]: shorewall.service: main process exited, code=exited, status=143/n/a févr. 28 00:16:10 linux systemd[1]: Failed to start Shorewall IPv4 firewall.
and using nm which add auto_ to my ssid freebox_wdurio
CC: (none) => mageia, olav, thierry.vignaud
in fact nm create /etc/sysconfig/network-scripts/ifcfg-Auto_freebox_wdurio and drakfirewall think it is an interface (or it is one for networkmanager world ?)
if I remove the ifcfg file everything seems to work
CC: (none) => curtis_mageia
I just realized I was bitten by this bug again. To recap (using my situation as an example if I get this right): - On my laptop, I connected to a wifi at a local brewery. I'm using NetworkManager, but draknet is still configured. - The SSID is longer than 15 characters ("Field House Brewing - Public"). - files are created in /etc/sysconfig/network-scripts "ifcfg-Auto_Field_House_Brewing_-_Public" "keys-ifcfg-Auto_Field_House_Brewing_-_Public" - drakfirewall adds an entry to /etc/shorewall/interfaces Auto_Field_House_Brewing_-_Public - shorewall restarts resulting in the SILENT error (only shows on the commandline) iptables-restore v1.6.0: interface name `Auto_Field_House_Brewing_-_Public' must be shorter than IFNAMSIZ (15) - Since there was no error, the user continues working with NO FIREWALL! My workaround (not sure if all the steps are needed): - shorten all NetworkManager WiFi names that are longer than 15 characters #nmcli con show (to get the list of saved settings) - rename all the ifcg-* files to match the NM names with "ifcfg-" at the beginning - rename the keys-* files to match the ifcfg-* files - run drakfirewall. I'm able to just click OK through all the options. - test the firewall settings with "shorewall show" on the cmd line - if needed, run "shorewall restart" Seems like a pretty serious security issue to silently leave a user hanging with a wide open network connection (no firewall).
Target Milestone: --- => Mageia 6Assignee: mageia => mageiatoolsPriority: Normal => High
Having been hitten by this bug also a couple of time. For example the free access points in some airports are over 15 char... Once you have those long access point names listed on /etc/shoreline/interfaces, shoreline will fail to start silently.
CC: (none) => lamikr
Just ran into this again. How come this is still a problem?
I am using a mga6 with gnome and I select the wlan via gnome's menu. (instead of using drakconf for wifi selections) At least in this way the SSID's ends up to be added automatically to /etc/shorewall/interfaces file. At least for me the 15 char defined by the IFNAMSIZ is the limit (remembered incorrectly on previous mail that it was 20 chars) So if I add to /etc/shorewall/interfaces net 012345678912345 detect shorewall will still be able to start ok with command systemctl restart shorewall.service But if I instead add net 0123456789123456 detect systemctl restart shorewall.service fails and systemctl status shorewall.service ● shorewall.service - Shorewall IPv4 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2017-11-08 23:51:48 PST; 5min ago Process: 19823 ExecStop=/sbin/shorewall $OPTIONS stop (code=exited, status=0/SUCCESS) Process: 19891 ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS (code=exited, status=143) Main PID: 19891 (code=exited, status=143) Nov 08 23:51:48 localhost.localdomain shorewall[19891]: ipset v6.30: The set with the given name does not exist Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Processing /etc/shorewall/tcclear ... Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Preparing iptables-restore input... Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Running /sbin/iptables-restore... Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Processing /etc/shorewall/stopped ... Nov 08 23:51:48 localhost.localdomain shorewall[19891]: /usr/share/shorewall/lib.common: line 93: 20090 Terminated $SHOREWALL_SHELL $ Nov 08 23:51:48 localhost.localdomain systemd[1]: shorewall.service: Main process exited, code=exited, status=143/n/a Nov 08 23:51:48 localhost.localdomain systemd[1]: Failed to start Shorewall IPv4 firewall. Nov 08 23:51:48 localhost.localdomain systemd[1]: shorewall.service: Unit entered failed state. Nov 08 23:51:48 localhost.localdomain systemd[1]: shorewall.service: Failed with result 'exit-code'.
I'm pretty sure (but not positive) the problem is in http://gitweb.mageia.org/software/mandi/tree/src/plugins/ifw/ipset.c The package no longer has a maintainer. Unless this problem can be fixed, I'll be recommending that mandi be dropped from Mageia 7. The workaround for now is to uninstall mandi and mandi-ifw. You will no longer get the notifications of someone running a port scan against you, etc., but at least shorewall will not be disabled. Note that when using mcc to configure the firewall, select cancel when it asks to install mandi.
Source RPM: drakx-net-text-1.18-1.mga3 => mandi-1.4-2.mga6CC: (none) => davidwhodgins
Hi guys I used networkmanager first than I came back on draknet, and tried again networkmanager because it seems to be the one by default, etc... And they didn't like to be connect on the same wifi which is 14 char long, and networkmanager renamed it by appending "-1" at the end. Now it is 16 char long, and the firewall is not available anymore. One work around suggested was uninstalling mandi. I look on the SC given by Dave Hodgins, and I wonder why not changing IFNAMSIZ from 16 to 32 ? I saw it here /usr/include/linux/if.h LINE 31 : #define IFNAMSIZ 16 Now the wifi name are much bigger than before, isn't it time to increase this limit ? Or, changing mandi with a dynamic length instead of a fixed one ? Jibz
CC: (none) => j.biernacki
Workaround with uninstalling of mandi doesn't work for me. Only working workaround is remove long interface from /etc/shorewall6/interfaces /etc/shorewall/interfaces After that, shorewall(6) starts properly.
CC: (none) => joelp
The code in /usr/include/linux/if.h says: #if __UAPI_DEF_IF_IFNAMSIZ #define IFNAMSIZ 16 #endif /* __UAPI_DEF_IF_IFNAMSIZ */ #define IFALIASZ 256 Why can't we then use IFALIASZ instead or check if the name is too long and then use it? I'm no programmer, but like mentioned in comment #13, this should me changed or hacked somehow. Cheers, Stig
CC: (none) => smelror
Options for dealing with this bug. 1) Fix drakfirewall so that when it configures mandi-ifw, it doesn't try to use the ssid where shorewall expects an interface name, as the ssid can be too long. If something unique to the wireless access point is needed, use something shorter such as the mac address. 2) Modify shorewall to allow an interface name that's longer (256 bytes). 3) Remove the option to try to use the ifw from drakfirewall, since it may set up the ifw with broken configurations anyway. 4) Drop the packages drakfirewall, mandi, and mandi-ifw. 5) Leave everything as is, knowing that the existing system breaks shorewall if the system is configured to access a wireless access point with an ssid that is over 15 bytes in length. After 6 years, I don't want to see yet another release go out with option 5.
The same problem on WIFI with SSID shorter than 15 chars. If you have more APs with same SSID, it produce interfaces like 14CHARSSID-1, 14CHARSSID-2, ... 14CHARSSID-N. What leads to have more than 15 chars internaface name.
Hi, Nice bug report, very useful, as I found today why I had to remove completely the firewall if I wanted to allow remote backup of my laptop by my university. Which was bad in terms of security, is not it? This because I got as a disease a SSID longer than 15 characters. So the bug is still present as of Feb 2020. I humbly suggests to edit drakfirewall to any of the valid options above, even option "get rid of drakfirewall and propose something else". and keep on the good work (i.e. almost everything else!)
CC: (none) => gilles.duvert
It's not suggesting getting rid of the firewall, just the part called the interactive firewall. Removing the package mandi-ifw and mandi, is all that's needed. The shorewall package still controls the loading of the rules for internet traffic (aka firewall rules). In linux, the actual firewall is called netfilter, and is part of the kernel.
Thanks for clarifying. However, at some point in the click an point process in the Mageia Control Center, I unchecked "Use Interactive Firewall" but the problem was still there. So it was not obvious the problem was on the interactive firewall side. The only way out was to remove the connection with a very long name using "Remove a Connection" (in the Network and Internet tab) before going to the "Security" tab and "Set up your personal firewall". Or, of course, not using MCC and remove the long 15+ culprit chain in /etc/shorewall/interface.
(In reply to Dave Hodgins from comment #19) > It's not suggesting getting rid of the firewall, just the part called the > interactive firewall. Removing the package mandi-ifw and mandi, is all that's > needed. The shorewall package still controls the loading of the rules for > internet traffic (aka firewall rules). In linux, the actual firewall is > called > netfilter, and is part of the kernel. That's not true. I have no packages mandi-ifw or mandi and shorewall not works with log interface names #journalctl -u shorewall iptables-restore v1.8.2 (legacy): interface name `SOME-LOG-SSID-NAME' must be shorter than IFNAMSIZ (15) úno 25 12:47:53 localhost.localdomain shorewall[12265]: Error occurred at line: 124 úno 25 12:47:53 localhost.localdomain shorewall[12265]: Try `iptables-restore -h' or 'iptables-restore --help' for more information. úno 25 12:47:53 localhost.localdomain shorewall[12265]: ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input úno 25 12:47:53 localhost.localdomain root[12738]: ERROR:Shorewall start failed
(In reply to Luděk Janča from comment #21) > That's not true. I have no packages mandi-ifw or mandi and shorewall not > works with log interface names > > #journalctl -u shorewall > iptables-restore v1.8.2 (legacy): interface name `SOME-LOG-SSID-NAME' must > be shorter than IFNAMSIZ (15) What created that rule? The interface name should be something like eth0, or enp2s0, or p32p1. If you don't use mandi, then what created that rule? It's supposed to be the name of the network device, not an ssid. Shorewall only uses it for the messages it generates, so the mandi author(s) decided to put the ssid in that field for the messages, but it fails with an ssid name that is longer than what a network interface name is limited to, which makes mandi generate rules that shorewall cannot process.
(In reply to Dave Hodgins from comment #22) > (In reply to Luděk Janča from comment #21) > > That's not true. I have no packages mandi-ifw or mandi and shorewall not > > works with log interface names > > > > #journalctl -u shorewall > > iptables-restore v1.8.2 (legacy): interface name `SOME-LOG-SSID-NAME' must > > be shorter than IFNAMSIZ (15) > > What created that rule? The interface name should be something like eth0, > or enp2s0, or p32p1. If you don't use mandi, then what created that rule? > > It's supposed to be the name of the network device, not an ssid. Shorewall > only uses it for the messages it generates, so the mandi author(s) decided > to put the ssid in that field for the messages, but it fails with an ssid > name that is longer than what a network interface name is limited to, which > makes mandi generate rules that shorewall cannot process. Looks like that interfaces were from the past. After that I deleted interfaces, shorewall works well. Using NetworkManager. For now, it's needed to do not use interactive firewall.
Ping. See comment 16 and comment 19 about dropping mandi and mandi-ifw Increasing priority and severity. This is a release blocker for Mageia 8.
Priority: High => release_blockerSeverity: major => critical
Instead of using the ssid in the shorewall rule, I recommend using a hash. The result must be 15 bytes or less, i.e. 120 bits or less. How about replacing the ssid with an xxh64sum value. That would add a requires for the xxhash package, and the code to replace the ssid with the "xxh64sum ssid" output.
Does mandi still work? I've just tried activating it, but I don't see any notifications.
CC: (none) => mageia
My second question is whether drakfirewall should be adding the SSID-based interfaces to /etc/shorewall/interfaces at all. Isn't adding the physical interface enough?
I have no idea how it actually works and have never used it, but could it be to allow opening ports on your home wifi and not leaving them open when using a public wifi on the same interface?
CC: (none) => pterjan
My understanding is that all it does is generate notification messages that inform the user an attack has been blocked. Useless messages that just clutter the screen, in my opinion. All it does is panic users who don't understand that it's only notifying them about packets that have been blocked. Since they have been blocked, what's the point of notifying the user about the "attack"? While it's mandi and mandi-ifw that trigger it, it appears to be /usr/lib/libDrakX/network/ifw.pm that actually handles the notification message and /usr/lib/libDrakX/network/drakfirewall.pm that is adding the rule to iptables. In cauldron, it doesn't appear to be working anyway. Another reason to seriously consider dropping it. drakfirewall would have to be modified to not display the Interactive firewall screen or install mandi and mandi-ifw.
The point of interactive firewall is that if this is something you wanted to work (for example you started some streaming, some vpn, mounted a remote disk or something) you can tell it to allow that traffic when you get the notification that it was blocked. When you get a notification it has buttons "Blacklist", "Whitelist" and "Ignore".
So far, testing on mga7, I have been unable to get any notifications. Opening the interactive firewall control panel from net_applet, I do see a connection in the log, and can blacklist it. The mandi service is disabled by default, even after you run drakfirewall. So it doesn't work on new installs unless the user manually enables it. As far as I can tell, this bug only occurs if you are using NetworkManager, which creates the extra ifcfg-* files in /etc/sysconfig/network-scripts. But most people using NM won't be using net_applet, so won't see the interactive firewall anyway. IIRC, tmb said he had to patch the kernel to support the interactive firewall. So that's an extra maintenance burden.
Digging into this, I don't think this bug is related to mandi (borne out by comment 14). I believe it is solely due to using NetworkManager. NM stores its wireless config files directly in /etc/sysconfig/network-scripts, whereas when using the legacy network service, the wireless config files are stored one level down in /etc/sysconfig/network-scripts/wireless.d. The drakx-net network::read_net_conf() subroutine assumes all ifcfg-* files it finds in /etc/sysconfig/network-scripts are real network interfaces. So the fix for this bug is to filter out the NM wireless config files. It would also be good to make drakfirewall report if shorewall fails to start.
Created attachment 11801 [details] Patch to fix the bug This patch fixes the bug for me, tested on a mga7 system. If any one cares to test it themselves: su - cd /usr/lib/libDrakX patch -b -p2 < <path to>/network.patch replacing <path to> with wherever you saved the file.
Keywords: (none) => PATCHTarget Milestone: Mageia 6 => Mageia 8Source RPM: mandi-1.4-2.mga6 => drakx-net
It's not currently possible to report an error if shorewall fails to start because services::_run_action() calls systemctl with the --no-block option, so it doesn't see the error.
Hi, This is release_blocker for a reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please change the status to "Assigned" when you are working on this. We will make a decision on the relevance of the release_blocker tag on 1st October 2020 QA meeting.
Status comment: (none) => fixed in gitAssignee: mageiatools => mageia
Fix released in drakx-net 2.52
Status: NEW => RESOLVEDResolution: (none) => FIXED