If you are using a virtual NIC (or unsupported hardware that results in netmap using its generic adapter), then it's possible you still get a hang. What it should do is simply overwrite the existing Suricata binary with this new version.Īfter installing the new binary, repeat your speed tests and see if things are more stable. I would download the package using the URL in the link I provided and then store it locally on the firewall (maybe in /tmp or /root), then install it from there. Then, once it is running (I realize it quickly crashes), go to a shell prompt and install the test package using the pkg utility like so: pkg install Get OPNsense up and running on the device with Suricata installed/enabled/configured (or whatever you normally do to use Suricata in OPNsense). I have never used OPNsense, so I can't tell you exactly how to install the test package. The OPNsense developer prepared the test Suricata package to see, and that's the package I was hoping you might could test. I am hoping the patch I provided in the Suricata Redmine thread solves the stall issue.

But heavy traffic loading can lead to the stall as you experienced when I suggested earlier in this thread to switch to runmode = workers. Typical usage with sort of low data rates will not cause the bug to manifest when using Suricata on pfSense. The bug identified affects both, but due to having only a single pair of host stack rings OPNsense Suricata is more vulnerable to the stall. It gets technical, but Suricata on OPNsense uses netmap with only a single pair of host stack rings while we have been using multiple host stack rings with Suricata on pfSense.

Suricata in OPNsense would be suffering from the bug this proposed patch corrects. Tell me how I can install this patch and how you want me to test this. Still have my OPNsense proxmox VM, which run for 9 months until.

Yes have it with pfsense configured as backup. Said in 6100 SLOW in comparison to Protectli Hi

Protectli fw6e