Hide Forgot
Created attachment 1843257 [details] cidr-format list (IPv4) A few days after upgrading from f34 to f35, I went to add an updated set of IPs to the drop zone using firewalld (1.0.1). This is something I have done on a weekly basis for some time now, because I often run a streaming audio server (Icecast) that can be accessed from outside my LAN, and a comprehensive set of IPs in the drop zone has significantly reduced what used to be incessant attempts at compromising my device. I was surprised to see CPU usage spike to 25% upon importing my largest CIDR list (11057 entries, 72640 subnets, IPv4) from the file chooser, and the task did not complete for about 17 minutes, with CPU usage remaining around the aforementioned level for the duration. The task completed without error, though the time and resource-usage was highly concerning. For reference, under Fedora 34 w/firewalld 0.9.4, the same task would never take more than ten seconds. The situation was similarly quick under Fedora 33 w/firewalld 0.8.6. This is all with lists of roughly the same size. I am uncertain about the root of this problem, and could find nothing in the logs which gives me a clue. I have attached the CIDR list I used in this operation. Hopefully this is reproducible and can be resolved. This seems potentially related to the following bug under RHEL 8: https://bugzilla.redhat.com/show_bug.cgi?id=2016822 P.S. I did some tests with smaller lists. As expected, the processing time increased significantly with the amount of subnets.
This is still an issue under Fedora 36 and 37.
The fix is in the below firewalld releases. How do you feel about rebasing firewalld to v1.2.1 (same as f37 and f38) ? It's a big version bump for an old release. $ git tag --contains 36c170db265265e838a089858be4b20dbbd582eb v1.1.0 v1.1.1 v1.1.2 v1.1.3 v1.2.0 v1.2.1
Obviously not many others have noticed the issue, so thank you for the response. I was unaware of there being a fix, and that's great news. It would of course be awesome to see it backported to f36, as I usually keep my main PC one release behind the latest Fedora for 2 or 3 months while kinks and edge-cases are worked out, and I imagine that some other users take similar approaches to release upgrades.
> It would of course be awesome to see it backported to f36 Do you mean a backport of specific patches.. or a rebase to v1.2.1? The latter is actually less time consuming for your friendly maintainer. ;)
Ah, then of course the latter. I'm but a lone user with a relatively obscure issue, and only maintain one - much less complicated - package myself. I can offer you my heartfelt appreciation for any time you spend on a rebase.
(In reply to niohiani from comment #5) > Ah, then of course the latter. I'm but a lone user with a relatively obscure > issue, and only maintain one - much less complicated - package myself. I can > offer you my heartfelt appreciation for any time you spend on a rebase. I'll do the rebase. It may rot in bodhi (testing), but at least you'll have a build for yourself.
Many, many thanks, and godspeed!
FEDORA-2022-2305f92d83 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83
(In reply to Fedora Update System from comment #8) > FEDORA-2022-2305f92d83 has been submitted as an update to Fedora 36. > https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83 It should hit testing soon. I set the karma threshold to 5 (up from 3) since it's a rebase in an old release.
Stellar! Saves me a lot of time when importing new lists. Mark this as closed whenever you see fit.
FEDORA-2022-2305f92d83 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2305f92d83` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Created attachment 1924078 [details] Latest CIDR list (IPv4) for testing
Alright, so I'm using the new build, and while there are no noticeable regressions, this bug appears to be unresolved. I have attached the latest CIDR list I'm working with, and made sure to clear all of the previous entries before importing the new list under IPSets. It took about 15 minutes for the import to complete. Would love to assist in getting to the bottom of this.
Can you show the exact commands you're using? --->8--- # dnf info firewalld Installed Packages Name : firewalld Version : 1.2.1 Release : 1.fc37 [..] # firewall-cmd --permanent --new-ipset foobar hash:net # time firewall-cmd --permanent --ipset foobar --add-entries-from-file=big_set success real 0m0.253s user 0m0.151s sys 0m0.020s [root@vm-local-fedora tmp]# wc -l big_set 10611 big_set
Pretty weird. Importing via the GUI (firewall-config) is still extremely slow, but doing so via the command line appears to have been fixed, and only takes seconds. Didn't think to try adding via firewall-cmd since I filed this bug, as I usually only use firewall-cmd for backing up previous IPSet entries, and tend toward the GUI for other operations. Will be avoiding firewall-config for now.
FEDORA-2022-6499e05ba6 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6499e05ba6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6499e05ba6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-6499e05ba6 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.