I guess “standoff” might be me being a bit hyperbolic 
I spotted a couple of open issues on integrating ndpi 5 into Suricata and discussion on who which project was responsible for making sure it worked still
Suricata 8.0.4 was released 12 days ago. I guess they fixed the issue with ndpi 5.0.
v2.0.0 released: Suricata 8.0.4 with nDPI 5.0 and Vectorscan
If you are using a release candidate, please backup ips-policy.conf, or any .rules file before updating.
For future releases, just go to the project’s main page.
Just popping back in to report no issues running v2 so far 
Thanks again for all the work @Unflawed
Running v2 as well with full inline and getting 2.2Gb download.. and 2.37 Gb upload so I’d say pretty goods.
Question though.. you all say inline runs through CPU but mine doesn’t seem to?
There should still be a cpu usage spike when doing a speed test. It sounds like there’s packet acceleration happening and this can bypass Suricata in inline mode. Would you mind showing the result of ./runner.sh status
Also do you have alta bits set to 4? I don’t have it.
Also yes on the bit 4
Bundled System: aarch64
Components: Suricata 8.0.4
nDPI 5.0
Vectorscan 5.4.12
Vectorscan Runtime: present
Policy IPS_INLINE: 1
Active Policy IPS_INLINE: 1
Policy ENABLE_NDPI: 1
Policy ENABLE_WEBSOCKET: 1
Policy ENABLE_WEBSOCKET_RULES: 1
Policy ENABLE_NDPI_BYPASS: 1
Policy ENABLE_NDPI_SECURITY: 0
Policy ENABLE_AUTO_UPDATE: 0
Suricata Process: running
IPS Daemon: running
Mode: Inline IPS
Matcher: mpm-hs active (Vectorscan)
nDPI Plugin: enabled
WebSocket Parser: enabled
WebSocket Rules: enabled
nDPI Bypass Rules: enabled
nDPI Security Rules: disabled
Rules: [16511 - Suricata-Main] 2026-04-01 15:03:58 Info: detect: 3 rule files processed. 25946 rules successfully loaded, 0 rules failed, 0 rules skipped
Rule Update Schedule: 30 3 * * * /usr/bin/suricata-update --fail --no-test
Rule Pruning Schedule: 32 3 * * * /cfg/suricata-runner/scripts/post-update-prune.sh
Runner Auto-Update: unavailable
Boot Persistence Hook: enabled
Try removing or renaming the alta bits 4, reboot, and run speed test again via browser after 2 minutes.
I will have to try in a little but if it requires that to be off I know I’m probably gonna get knee capped lol
Nice work @Unflawed . I’ve been working this in parallel recently and just saw your work. I’ve done some of the same, some additional separate work in reducing update memory consumption as suricata-update is horribly memory inefficient, and am adding some configurable options to help greatly cut down the signature count.
Whether you want to disable offload when running suricata depends on your goals. But the consideration is the same whether in inline mode or IDS mode. In the former, NFQ has the mid-stream of traffic hidden from iptables when offload is enabled, in the latter libpcap has the exact same thing occur. New connections aren’t offloaded immediately, it takes ~100 or more packets before it’s offloaded, which is sufficient for the vast majority of signatures to match considering what they’re looking for. Very few of those will end up matching anything later in a stream, so it’s often basically functionally equivalent to leave offload enabled. But if you want 100% complete analysis of everything in either inline or IDS mode, you need to disable hardware acceleration.
I expect we’ll have this done and released this month.
I tried with alta_bits 4 and Suricata is scanning packets but ndpi seems to be in play after checking the logs. There is an ndpi bypass for Ookta, so download speed reaches almost line speed.
I tried mine on fast.com, speedtest.net, and my decos have a built in speed test but guess I need to speed test by doing a download or something.