# RFC: Solaris DLPI inline IPS support

**URL:** <https://forum.suricata.io/t/rfc-solaris-dlpi-inline-ips-support/6528>\
**Category:** Developers\
**Tags:** ips, suricata\
**Created:** [October 18, 2026, 12:32pm UTC](https://forum.suricata.io/t/rfc-solaris-dlpi-inline-ips-support/6528 "2026-10-18T12:32:55Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![mrehak](https://avatars.discourse-cdn.com/v4/letter/m/82dd89/32.png) [@mrehak](https://forum.suricata.io/u/mrehak)\
**Post date:** [October 18, 2026, 12:32pm UTC](https://forum.suricata.io/t/rfc-solaris-dlpi-inline-ips-support/6528/1 "2026-10-18T12:32:55Z")

</div>

Hello,

while deploying Suricata on Oracle Solaris I have asked codex to develop mininal IPS support for Solaris DLPI. I am not keen either on Suricata nor network internals so my understanding of the patch is limited.

My question is whether at all you would be interested in discussing and potentially merging such change. I understand that the code is AI generated and you may not want it in the repo at all. I am open to discussion, making changes and maintaining and testing the code in case it is needed.

I am a new user, so I have no option to upload attachments.

Thank you for your time,

Martin

This is what codex says about the implementation:

It uses libdlpi raw mode, physical and SAP promiscuity, and transmit  
loopback suppression. No kernel change, packet-filter divert interface  
or kernel verdict mechanism is required. Dedicated bridge ports must  
have no IP addresses or alternate forwarding path. With Suricata  
stopped, the userspace bridge does not forward traffic.

The scope is deliberately limited: Ethernet, workers, one thread per  
input link, and copy-mode: ips. Receive batches check shutdown and  
link/read errors trigger delayed handle reopen. Transmit remains  
blocking; this is not a throughput or bounded-shutdown claim.

The 8.0.7 downstream build was validated separately on native Solaris  
x86-64 and SPARC: component tests, 14 mocked receive-loop cases on each,  
fresh package installation, and bidirectional raw-frame allow/drop  
tests on isolated virtual Ethernet pairs. Per architecture, allow  
forwarded 36 byte-identical frames; drop rules blocked 24 IPv4/IPv6  
frames and forwarded 12 ARP/experimental frames. The stopped-engine  
tests forwarded zero frames. Physical-NIC performance, TCP stream  
reassembly and fragmentation qualification have not been performed.

And this is a summary of testing being made:

Architecture x86-64 SPARC  
Build / package publish PASS PASS  
Component test target PASS PASS  
C engine tests passed 2599 2570  
Additional hash tests passed 2 2  
Rust tests passed 1257 1257  
Rust tests ignored 2 2  
Targeted receive-loop cases 14 PASS 14 PASS  
Fresh package install/verify PASS PASS

Installed-package traffic tests, independently on each architecture:

- Two isolated virtual Ethernet pairs; both forwarding directions.
- Six frame types: ARP, IPv4/ICMP, IPv6/ICMPv6, VLAN-42 IPv4,  
VLAN-42 IPv6 and experimental EtherType 0x88b5.
- Three repetitions per type per direction: 36 frames per profile.
- Allow: 36 byte-identical frames arrived; no duplicates or modifications.
- Drop IPv4/IPv6 rules: 24 IP frames blocked, 12 other frames arrived.
- Suricata stopped before and after: 0 frames forwarded.
- Verdict counters and alerts matched; capture.dlpi\_send\_errors was 0.