Description of problem: I used dnf to upgrade Fedora 36 => 38. Some important firewall settings were lost. I think that I fixed them in Runtime. I switched to Permanent and immediately got a box saying | Error | 'NoneType' object has not attributr 'export_config' | OK | Quit I chose OK and the crash happened. So I'm reporting two symptoms: - settings silently lost on upgrade - crash Version-Release number of selected component: firewall-config-1.3.1-1.fc38 Additional info: reporter: libreport-2.17.10 package: firewall-config-1.3.1-1.fc38 uid: 1104 interpreter: python3-3.11.3-1.fc38.x86_64 type: Python3 exception_type: AttributeError reason: firewall-config:7061:load_direct:AttributeError: 'NoneType' object has no attribute 'getAllChains' crash_function: load_direct runlevel: N 5 kernel: 6.2.15-300.fc38.x86_64 cmdline: /usr/bin/python3 -sP /usr/bin/firewall-config executable: /usr/bin/firewall-config cgroup: 0::/user.slice/user-1104.slice/user/app.slice/app-gnome-firewall\x2dconfig-5389.scope Truncated backtrace: firewall-config:7061:load_direct:AttributeError: 'NoneType' object has no attribute 'getAllChains' Traceback (most recent call last): File "/usr/bin/firewall-config", line 2374, in onChangeView self.load_direct() File "/usr/bin/firewall-config", line 7061, in load_direct chains = settings.getAllChains() ^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'getAllChains' Local variables in innermost frame: self: <__main__.FirewallConfig object at 0x7fd5427a9690> direct: <firewall.client.FirewallClientConfigDirect object at 0x7fd5427fc150> settings: None
Created attachment 1966343 [details] File: namespaces
Created attachment 1966344 [details] File: mountinfo
Created attachment 1966345 [details] File: open_fds
Created attachment 1966346 [details] File: environ
Created attachment 1966347 [details] File: backtrace
Created attachment 1966348 [details] File: cpuinfo
Created attachment 1966349 [details] File: os_info
New symptom: I try to go to the Permanent configuration. I get a message that says: | Error | RUNNING_BUT_FAILED. Changing permanent configuration is not allowed while | firewald is in FAILED state. The permanent configuration must be fixed and then | firewalld restarted. Try `firewall-offline-cmd --check-config`. | OK | Quit I try the suggested command. It is silent. I'm stuck in this bad state.
Created attachment 1966350 [details] message from firewalld GUI
Created attachment 1966353 [details] firewalld log It looks to me as if the root cause is a malformed iptables save file. I don't know where it lives so I cannot examine it. The iptables-restore command somehow takes "--in-interface=ppp0" as an interface name. My guess is that the problems cascade from there.
I issued these command, probably in September 2020 (some of the network address is obscured): $ sudo firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 --in-interface=ppp0 --destination 192.x.x.0/24 --jump DROP $ sudo firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 --in-interface=ppp0 --destination 192.x.x.0/24 --jump DROP This is probably relevant. This must have been before Fedora 36. I don't think that it caused a problem when I upgraded to Fedora 36.
I renamed /etc/firewalld/direct.xml to /etc/firewalld/HIDE.direct.xml. Restarting firewalld after this works. So my server is back on its feet but is missing this direct rule. The firewalld behaviour that I observed is not good. Error handling should be better. At this point, I'm not sure that the --direct command that I issued in 2020 is now incorrect.
The failure is in the --direct commands. These are iptables commands. Firewalld can not do semantic checking of those which is why it fails during startup and is not caught by --check-config. Your log file makes this clear. ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.9 (legacy): interface name `--in-interface=ppp0' must be shorter than IFNAMSIZ (15) Error occurred at line: 2 Try `iptables-restore -h' or 'iptables-restore --help' for more information. A couple things to try: 1) Use the "-i" option instead of "--in-interface" 2) start the daemon with --debug=9 (see /etc/sysconfig/firewalld) to show the actual commands sent to iptables-restore
(In reply to Eric Garver from comment #13) > ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.9 > (legacy): interface name `--in-interface=ppp0' must be shorter than IFNAMSIZ > (15) > Error occurred at line: 2 > Try `iptables-restore -h' or 'iptables-restore --help' for more > information. This is a bug introduced in upstream version 1.8.8 and fixed in commit 90a7a183a208b ("xshared: Fix parsing of option arguments in same word") which is not yet part of a release. I'll go prepare bugfix releases for Fedora to cover this.
The issue will be fixed in iptables-1.8.9-4.fc38. A workaround until it has landed is to use short options (i.e., '-i eth0' instead of '--in-interface=eth0').
Thanks Phil! I'm reassigning this bug to iptables.
Closing as per comment 15.