pfSense » pfSense Packages

Actually inverting it doesn't work either, removing it seems to be better. In my case when clicking "Show" on any of the lists in the Webinterface (HOME_NET, LOCAL_NET etc.) showed an empty list, with that check inverted the PASS_LIST is messed up, removing that check seems to work though.

This affects CE aswell as Plus. Snort version is 4.1.6. Reproduction steps are described in the first comment:

Flole Systems wrote in #note-1:

In my case when clicking "Show" on any of the lists in the Webinterface (HOME_NET, LOCAL_NET etc.) showed an empty list, with that check inverted the PASS_LIST is messed up, removing that check seems to work though.

I am the Snort package maintainer and tested this in a current pfSense-2.7.0-DEVEL snapshot with the most recent Snort package for DEVEL installed. I was not able to reproduce the behavior described by the OP. The HOME_NET, EXTERNAL_NET, and PASS_LIST parameters all show up with the expected values populated in the modal dialog.

If the OP is indeed running the 4.1.6 version of Snort on a DEVEL snapshot, that will definitely have issues as that version of the package has many PHP 8.1 bugs in it. One other possibility is that the drop-down selector on the INTERFACE SETTINGS tab for those parameters (HOME_NET, EXTERNAL_NET, etc.) is truly blank instead of containing "default". The PHP code does expect either a valid list name there or the choice "default". What value is actually listed in the drop-down selector on that tab? Is it possible the list shown as selected in the drop-down control is actually no longer present on the system (possibly it was deleted)? Version 4.1.6_1 of the package did fix an older bug that allowed the user to delete a Pass List that was still assigned to an interface. Perhaps that happened in the OP's case?? The package code will now no longer permit an actively assigned list to be deleted until it is unassigned from all Snort interfaces.

Snort-4.1.6_1 (note the underscore '1') is the Snort package version containing the PHP 8.1 fixes for pfSense-2.7.0-DEVEL. If you are testing on the latest DEVEL snapshots, be sure you have the 4.1.6_1 version of the package installed. But also note that there is an issue with pkg and pfSense add-on packages that start a binary process as part of the package installation process in the current DEVEL snapshots. The package will install, but the pkg utility will then "hang" waiting for the installation to complete because pkg is not properly handling the spawning of the binary process. So, when installing Snort or Suricata (and a few other packages), you will need to locate and manually kill the rc.packages script that is waiting.

I didn't test it on the dev version, I only tested the latest plus and CE release versions.

For me the check I mentioned above is causing the list to be empty as it's returning an empty list. Removing that check causes a list to appear. Maybe you could check why in your case that check isn't causing an empty list to be returned? Maybe we can figure out this way why a certain code path was taken which results in unexpected behavior.

Flole Systems wrote in #note-5:

I didn't test it on the dev version, I only tested the latest plus and CE release versions.

For me the check I mentioned above is causing the list to be empty as it's returning an empty list. Removing that check causes a list to appear. Maybe you could check why in your case that check isn't causing an empty list to be returned? Maybe we can figure out this way why a certain code path was taken which results in unexpected behavior.

That check returns an empty list when it can't find the list name that was passed. So the logic of the check is correct in that sense.

I will test against the current RELEASE version and report back on whether I can replicate the issue or not. I only tested with the new package on the DEVEL snapshot.

I am unable to reproduce this in the current RELEASE version of the Snort package. All of the referenced lists (HOME_NET, EXTERNAL_NET, and PASS LIST) populate and display properly. I tested both using the "default" list name selected as well as with another custom list name selected.

I believe what has happened in the OP's case is the list name being looked up does not actually exist as a valid entry in the config.xml file, thus when

snort_find_list($listname)

Can you post a screenshot of the section of the INTERFACE SETTINGS tab showing the drop-down select for HOME_NET and EXTERNAL_NET? Perhaps this is a language or multibyte character set issue ?? I am in the USA, and using English naming conventions it works fine for me.

You are absolutely right, the name passed is the german version of "default", which should have been covered by the check above, but isn't as it's not "default" even though it should. Instead of the value of the dropdown the display string is used for the request, which then causes it to fail, replacing text() with val() fixes it. I've seen something similar at another package/plugin where nobody thought about the consequences of having multiple languages...

Flole Systems wrote in #note-8:

You are absolutely right, the name passed is the german version of "default", which should have been covered by the check above, but isn't as it's not "default" even though it should. Instead of the value of the dropdown the display string is used for the request, which then causes it to fail, replacing text() with val() fixes it. I've seen something similar at another package/plugin where nobody thought about the consequences of having multiple languages...

Thanks for the feedback and confirming a hunch (well, wild guess actually).

There is an if-then conditional test a little above where the empty list check is made where the list name is compared to "default". Probably need to wrap that "default" text string with a gettext() function call. Since I am an English-only, single language speaker, can you try that? Here is the complete snippet of code:

    if (!$externallist && ($listname == 'default' || empty($listname))) {
        $localnet = 'yes'; $wanip = 'yes'; $wangw = 'yes'; $wandns = 'yes'; $vips = 'yes'; $vpns = 'yes';
    }
    else {
                $list = snort_find_list($listname);
                if (empty($list))
                        return $list;

So change that to read this way and see if it works for you then:

    if (!$externallist && ($listname == gettext("default") || empty($listname))) {
        $localnet = 'yes'; $wanip = 'yes'; $wangw = 'yes'; $wandns = 'yes'; $vips = 'yes'; $vpns = 'yes';
    }
    else {
                $list = snort_find_list($listname);
                if (empty($list))
                        return $list;

If that works, then I will get some fixes submitted. Suricata will suffer from the same issue, and it may exist elsewhere in the code. Thanks for the report.

Update: just re-read your initial reply and see you offered another fix instead back on the INTERFACE SETTINGS tab. I will investigate that one, too.

A pull request has been submitted to the pfSense DEVEL branch of FreeBSD-ports to correct this issue. The pull request link is: https://github.com/pfsense/FreeBSD-ports/pull/1196.

Once the request is reviewed and merged, this issue can be marked resolved.

This has been resolved now, so the status is wrong.