Hi Stefaan,
On Wednesday 08 June 2022 20:32 Stefan Schantl wrote:
Hello Rob,
a big thanks for testing and reporting this issue here.
The main problem has been fixed a while a ago and also merged into next and the current master branch. So this should be a part of the upcomming core update.
After a deeper look I've found that the "rules.pl" file is currently not shiiped by C168 so the fix would not deplyed.
I suspected it was a problem in the 'ipset_restore' function of rules.pl but didn't delve too deeply, so I'm pleased you have a fix already.
As a workround I have managed the number of county codes blocked to be an even number (excluding the A1, A2, A3, and XD country codes), which seems to prevent duplicate ipsets being generated.
@Peter: Please add this file to the C168 filelist.
A big thanks in advance,
I'm pleased I can be of some help.
-Stefan
Rob
Hi All,
The tests below were made on my 'Testing' APU4 using CU 168 but as Adolf has found was identified as CU 167 in the GUI. However I am listing duplicate ipsets on my production 'Stable' APU4 with CU 167 installed.
Rob
On Tuesday 07 June 2022 15:51 Rob Brewer wrote:
If I list the installed ipsets with 'ipset -n list' additional ipsets with the suffix 'v4' are sometimes listed. From what I can see this additional 'v4' list is the same size as the set without the 'v4' extension.
For instance: with just code AR selected with location-block.cgi:
[root@ipfire-dev2 ~]# ipset -n list ARv4 AR (code AR id duplicated)
if I add code AT to AR and list the sets: [root@ipfire-dev2 ~]# ipset -n list AT AR (as expected)
and now add code AW to the other 2: [root@ipfire-dev2 ~]# ipset -n list ARv4 AT AR ATv4 AW (now codes AR and AT are duplicated)
I see this effect on both my core 167 boxes and wasn't aware of this problem before my upgrade from core 161.
Rob