DEV Community: Alex Root

Building a High-Performance eBPF/XDP Policy Engine in Rust

Alex Root — Sun, 16 Aug 2026 18:56:14 +0000

A Bit of Background

The origins of eBPF (extended Berkeley Packet Filter) can be traced back to the original Berkeley Packet Filter (BPF), which was introduced in the early 1990s as a mechanism for filtering network packets. Over time, BPF evolved from a packet filtering framework into a general-purpose execution environment within the Linux kernel, ultimately becoming what we now know as eBPF.
Today, eBPF is far more than a networking technology. It is widely used for observability, performance monitoring, security enforcement, networking, load balancing, and many other kernel-level tasks. Instead of requiring developers to write and maintain custom kernel modules, eBPF allows sandboxed programs to run safely inside the kernel.
Before an eBPF program can be loaded, it must pass the kernel verifier. The verifier performs a static analysis to ensure that the program always terminates, accesses memory safely, and complies with the kernel's security constraints. This verification process enables eBPF to extend kernel functionality without compromising system stability or security.
One of eBPF's greatest strengths is its flexibility. Programs can be attached to multiple execution points—known as hooks—throughout the kernel. Each hook exposes different information about the packet or system state and is designed for a particular class of workloads. Choosing the right hook depends on the required performance, the amount of available context, and the functionality that needs to be implemented.
To better understand where these hooks fit into the networking stack, let's first look at the path a network packet takes through the Linux kernel.

The diagram above shows the packet processing path between the network interface and the Linux networking stack. XDP operates exclusively on the receive (RX) path, where packets are processed before they reach the kernel networking stack. TC (Traffic Control), on the other hand, provides both ingress and egress hook points, making it possible to process traffic in both directions.
The earliest packet processing point is XDP (eXpress Data Path). An XDP program runs between the network device driver and the Linux networking stack, before the kernel allocates the sk_buff (socket buffer) structure. sk_buff is the primary kernel data structure used to represent a network packet as it moves through the Linux networking stack.
Because XDP operates at such an early stage, it provides extremely low processing latency and is well suited for high-performance packet filtering, ACLs, DDoS protection, and packet redirection.
Once an sk_buff has been created, the packet enters the Linux networking stack, where eBPF programs can be attached through the Traffic Control (TC) subsystem. Unlike XDP, TC operates on the sk_buff, giving the program access to additional packet context that is not available at the XDP layer. TC is also closely integrated with routing, QoS, conntrack, tunneling, and other kernel networking subsystems.
This makes TC a convenient layer for implementing NAT, load balancing, packet modification, and more complex network processing.
XDP and TC are not the only eBPF attachment points. Cgroup hooks can be used to enforce policies for processes and containers, while socket filters can be used to inspect traffic associated with individual sockets. Tracepoints, kprobes, and uprobes are widely used for tracing and performance monitoring.
Although eBPF provides a wide range of attachment points, they are not interchangeable. The earlier a program runs in the networking stack, the lower the processing overhead, but the less context is available to it. As the packet moves further through the kernel, more context and functionality become available, but processing becomes more expensive.
Therefore, choosing an appropriate hook is fundamentally a trade-off between performance and functionality.
In Pulsar, XDP was chosen as the primary dataplane because it allows packet handling decisions to be made as early as possible, before the packet passes through most of the Linux networking stack. This makes XDP particularly well suited for high-performance ACLs and other early packet filtering mechanisms.
At the same time, the architecture is not limited to a single processing layer. Features that require richer packet context or deeper integration with kernel networking subsystems are planned to be implemented at the TC layer.

The Main Part

Over the years, the Linux networking stack has evolved to include a wide range of mechanisms for managing network policy. In addition to iptables and nftables, there are tools and systems such as firewalld, ufw, Docker, Kubernetes, and others that provide their own policy management interfaces or automatically modify existing filtering and routing rules.
As a result, administrators have to deal not only with the network policy itself, but also with the way that policy is implemented by a particular system. The same policy can be expressed in very different ways depending on the tool being used.
When moving between different platforms or introducing additional components such as Docker or Kubernetes, the changes go beyond policy syntax. The points at which policies are applied, the order in which traffic is processed, and the interactions between different networking mechanisms can all change.
A similar situation exists outside Linux as well. Many BSD systems and network devices use their own policy models and configuration approaches.
For example, consider the following simple filtering policy:

Deny TCP traffic from 192.168.0.3 to 192.168.0.202:80.

The same policy can look completely different depending on the system being used.

With iptables:

iptables -A INPUT -s 192.168.0.3 -d 192.168.0.202 -p tcp --dport 80 -j DROP

With nftables:

ip saddr 192.168.0.3 ip daddr 192.168.0.202 tcp dport 80 drop.

With pf:

block in proto tcp from 192.168.0.3 to 192.168.0.202 port 80.

All of the examples above describe the same network policy, but its representation depends on the underlying enforcement mechanism.
In the dataplane I am developing, the same policy is expressed through a single, unified interface:

./ebpf-ctl acl add drop  src 192.168.0.3:any  dst 192.168.0.202:80  proto=tcp

Or configuration file:

acl:
  drop:
    - src:
        addresses:
          - 192.168.0.3
        dst:
          addresses:
            - 192.168.0.202
        ports:
          number: 80
          proto: tcp

The goal is not to introduce yet another policy syntax, but to abstract policy definition away from its enforcement mechanism.

The user works with a single declarative network policy model that is independent of the underlying enforcement mechanism. The control plane translates this policy definition into an internal representation consumed by the dataplane, while the CLI and YAML are simply different ways of expressing the same policy.

Pulsar Architecture
The system follows the classic control plane / dataplane architecture: the control plane is responsible for building and distributing policy state, while the dataplane is responsible for processing individual packets.
" width="800" height="1069">

The diagram below illustrates the lifecycle of a policy, from its definition to its enforcement.
The system follows the classic control plane / dataplane architecture: the control plane is responsible for building and distributing policy state, while the dataplane is responsible for processing individual packets.
Control Plane and Dataplane
The primary mechanism for communication between the control plane and dataplane is BPF maps. The control plane uses them to pass prepared policy state to the dataplane: the control plane writes the policy state to the maps, while the dataplane reads it during packet processing.
Management Interfaces
Policy definitions enter the system through either a declarative configuration file (config.yml) or a command-line client. Both interfaces are intentionally kept thin: they pass the policy definition to the daemon and contain no policy interpretation logic of their own.
Daemon
The daemon is the core of the control plane. It converts the incoming policy definition into an internal policy model, performs validation and normalization, and then compiles the policy into a representation suitable for the dataplane.
At the final stage, the resulting structures are written to BPF maps.
Dataplane
The XDP program attached to the network interface accesses the BPF maps for every packet and makes the enforcement decision: whether to allow or drop the packet. It does not communicate directly with the control plane.
The configuration flow shown in the diagram goes from top to bottom. At runtime, however, data flows differently: the XDP program reads the policy state directly from the BPF maps.
Unified Policy Semantics
The same policy should have a consistent semantic representation regardless of whether it comes from the CLI, YAML, or another management interface.
To achieve this, all semantic processing—parsing, validation, normalization, and compilation—is centralized in the daemon, while management interfaces remain simple adapters to the internal policy model.
This separation allows management interfaces to evolve independently of the dataplane and makes it possible to introduce additional enforcement mechanisms without changing the underlying policy model.
BPF Maps as the Contract Between the Planes
In this architecture, BPF maps are more than just data structures. They serve as a contract between the control plane and dataplane.
The dataplane does not know where the policy came from, and the control plane does not need to know exactly how a packet will be processed. As long as both sides adhere to the same contract, the enforcement layer can be replaced—for example, with a TC/eBPF implementation—while the management interfaces can be extended without affecting the other plane.
This also provides an important operational property: a failure of the control plane does not affect the dataplane. If the daemon terminates, the XDP program continues to enforce the last policy state loaded into the BPF maps. Packet filtering therefore continues to operate even when the control plane is unavailable.
Current Capabilities
At the moment, Pulsar implements L3/L4 ACLs, IPv4 and IPv6 filtering, VLAN/QinQ ACLs, and rate limiting. Policy management is handled by a userspace control plane that supports declarative policy definitions.
Regardless of the management interface used, the dataplane receives the same internal representation of the policy.
Event Handling
Special attention is also given to event handling. The eBPF dataplane can send selected events to userspace through a Ring Buffer, where they are converted into loggable events.
The set of events to be logged is configurable, allowing the event generation mechanism to remain independent from how those events are ultimately represented or stored.
What Makes Pulsar Different
The main distinction of Pulsar is not the number of networking features it currently implements, but the architectural separation between the control plane and dataplane.
The control plane is responsible for defining, validating, and transforming policy, while the dataplane operates on the resulting prepared state to process packets.

Control Plane and Dataplane in Practice
The control plane runs in userspace. The CLI client sends commands to the daemon over a Unix socket, and the daemon writes the resulting rules to BPF maps: IP ACL for address-based filtering, VLAN ACL, and Rate Limit for controlling traffic intensity.
Because the policy state is stored in BPF maps, rules can be updated at runtime without reloading the XDP program.
The daemon also controls event logging through the Select Event configuration map. It specifies which events should be logged, and the XDP module sends only the selected events to the Ring Buffer, from which the daemon reads and processes them.

Dataplane
The dataplane operates directly on the driver's receive path. A packet arriving from the NIC reaches XDP before sk_buff is allocated and before the packet enters the Linux networking stack.
The XDP program matches the packet against the rules stored in the BPF maps and makes the corresponding decision.
If the packet is allowed, it continues through the normal Linux receive path and is processed by the networking stack. Depending on the configuration, it may subsequently pass through additional processing points, including TC ingress.
If the packet is denied, it is dropped as early as possible. This early-drop capability reduces the amount of work performed by subsequent layers of the networking stack, which is particularly important under high incoming traffic rates.
Traffic Processing in XDP
At the current stage, the main packet-processing logic in Pulsar is implemented in the XDP module.
For each packet, the XDP program accesses the BPF maps prepared by the control plane and uses the stored policy state to perform packet classification and enforcement.
Three basic mechanisms are currently implemented:

IP ACL
VLAN ACL
Rate Limiting

IP ACL
The IP ACL is responsible for filtering traffic based on IPv4/IPv6 and L4 parameters. It implements the basic allow/deny policies between sources and destinations.
When processing a packet, the XDP program extracts the required fields and constructs a lookup key for the ACL map. Depending on the policy, these fields may include:

source IP address;
destination IP address;
transport protocol, such as TCP or UDP;
source port;
destination port.

Based on the matching rule, the dataplane can allow the packet or drop it. If logging is enabled for that rule, the drop event is also sent through the Ring Buffer.
IPv4 and IPv6 are handled through a unified policy model. The control plane converts this model into the corresponding BPF map entries, so the dataplane does not need to parse configuration files or interpret policy definitions. It operates directly on the normalized policy state.
Importantly, the IP ACL in Pulsar is stateless. Each packet is evaluated based on its current fields and the loaded policy rules, without requiring connection-state tracking. This keeps packet processing lightweight and well suited to the XDP layer.
VLAN ACL
The VLAN ACL is designed to filter traffic based on 802.1Q and QinQ tags. Unlike the IP ACL, it operates on VLAN tags present in the Ethernet frame rather than IP addresses and transport ports.
This type of filtering is useful for several practical scenarios.
Network segment isolation. If an interface receives traffic from multiple VLANs, unwanted VLANs can be rejected at the host before the packets enter the Linux networking stack.
Protection against L2 configuration errors. For example, if a switch is misconfigured and traffic from one segment unexpectedly appears on another, a VLAN ACL can drop that traffic at an early stage.
Reducing the risk of VLAN hopping and handling malformed QinQ encapsulation. Unexpected or explicitly forbidden VLAN tags can be rejected before the packet is passed further into the Linux networking stack.
Unified declarative policy. In a traditional Linux environment, L2 and L3 filtering is often handled by different tools with different policy semantics. In Pulsar, VLAN policies are described using the same policy model as IP policies and loaded into the dataplane through the same control plane.
VLAN ACLs are particularly useful on bare-metal servers, hypervisors, edge nodes, and other infrastructure where a single physical or logical interface may receive traffic from multiple isolated segments.
There is, however, an important implementation detail to consider: network drivers can handle VLAN tags differently. In some configurations, the NIC may strip the VLAN tag in hardware and expose the VLAN information through packet metadata instead. Therefore, a correct VLAN ACL implementation needs to account for both VLAN tags present directly in the packet and VLAN information exposed through the XDP context.
Rate Limiting
Rate limiting in Pulsar is designed to control the amount of traffic allowed over a given period of time.
Each rate-limiting rule has its own state stored in a BPF map. This state contains the information required to calculate the current limit, such as the number of available tokens and the timestamp of the last update.
Comparison with Existing Solutions
There are several different approaches to implementing network filtering and programmable dataplanes.
Traditional solutions include iptables and nftables, while among modern eBPF-based platforms, Cilium and Calico are some of the closest architectural examples. There are also specialized eBPF dataplanes such as Katran, which focuses primarily on high-performance L4 load balancing.
Traditional Linux firewalls such as iptables and nftables are deeply integrated with the Linux networking stack and use the Netfilter subsystem to process packets. Configuration is performed through userspace tools that translate the specified rules into Netfilter state.
This approach is mature and well integrated into Linux, but the policy model and enforcement mechanism are closely tied to the particular firewall implementation.
Cilium is perhaps the closest example of using eBPF to build a programmable network dataplane. Cilium uses eBPF at different stages of packet processing, including XDP and TC, depending on the feature and configuration.
In addition to network policy, Cilium provides NAT, load balancing, routing, service networking, and many other capabilities. Therefore, in terms of the number of implemented features, Pulsar is currently far behind Cilium.
Calico provides another example of an eBPF-based dataplane. Its control-plane components translate network policies into state consumed by the dataplane. eBPF is used for filtering, routing, and other networking functions.
Like Cilium, Calico is a significantly more mature platform and is primarily focused on cloud-native and Kubernetes environments.
Katran is another interesting example. Unlike Cilium and Calico, it is not a general-purpose network security platform. Instead, it is a high-performance L4 load-balancer dataplane built on eBPF/XDP.
Its architecture demonstrates the performance benefits of moving packet processing to the earliest possible stages of the packet path. However, Katran's primary goal is fundamentally different from that of Pulsar.
Against this background, Pulsar is still at an early stage of development and does not attempt to compete with existing platforms in terms of feature count.
The current implementation focuses on building a programmable security dataplane in which security policy is separated from the underlying enforcement mechanism.
The key architectural idea is that policy is defined independently of the dataplane, transformed by the control plane into a formalized state, and then enforced directly by an eBPF program.
This separation allows the semantics of the policy and the packet-processing mechanism to evolve independently.
Test Environment
The test environment consisted of two single-board computers, an Orange Pi RV2 and an Orange Pi R2S, along with a MikroTik router.

Both single-board computers use a SoC from the SpacemiT K1 (Ky X1) family and the RISC-V 64-bit architecture.
The test setup consisted of:

Orange Pi RV2 (192.168.0.202) — the test machine running Pulsar.
Orange Pi R2S (192.168.0.3) — the test machine without Pulsar.
Verify That No Rules Are Currently Configured

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl list
(l4_acl map is empty)
root@orangepirv2:/home/orangepi/ebpf#

Make sure that logging has been disabled:

cat ./test.log 
2026-08-13T17:15:32.884095Z  WARN ebpf_daemon: Failed to load initial config config2.yml: io error: No such file or directory (os error 2)
2026-08-13T17:15:32.884379Z  WARN ebpf_daemon: Starting without configuration. Use 'ebpf-ctl reload <config>' to load later.
2026-08-13T17:15:32.995098Z  INFO ebpf_daemon::monitoring: Trying XDP program id: 237
2026-08-13T17:15:33.049185Z  INFO ebpf_daemon::monitoring: bpftool prog show id 237: 237: xdp  name xdp_dataplane  tag fa484001870657d5
    loaded_at 2026-08-12T07:52:31+0300  uid 0
    xlated 19776B  jited 8972B  memlock 20480B  map_ids 470,471,472,474,480,479
    btf_id 351
2026-08-13T17:15:33.103932Z  WARN ebpf_daemon::monitoring: Skipping map id 470: Map id 470 is not events ringbuf (name=counters, type=percpu_array)
2026-08-13T17:15:33.158030Z  WARN ebpf_daemon::monitoring: Skipping map id 471: Map id 471 is not events ringbuf (name=event_mask, type=array)
2026-08-13T17:15:33.212209Z  INFO ebpf_daemon::monitoring: Opened events map
2026-08-13T17:15:33.212382Z  INFO ebpf_daemon::monitoring: Events ringbuf size: 16777216 bytes
2026-08-13T17:15:33.219468Z  INFO ebpf_daemon::monitoring: Starting ringbuf event loop
root@orangepirv2:/home/orangepi/ebpf#

./target/debug/ebpf-ctl event-log list
event-log mask: 0x0
enabled events:
  [ ] PacketDrop
  [ ] RateLimited
  [ ] ConntrackMiss
  [ ] BackendSelected
  [ ] SlowPath
  [ ] ServiceMatched
  [ ] VlanDetected
  [ ] PacketAllow

./target/debug/ebpf-ctl event-log enable  PacketDrop
enabled event-log: PacketDrop
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl event-log list
event-log mask: 0x2
enabled events:
  [x] PacketDrop
  [ ] RateLimited
  [ ] ConntrackMiss
  [ ] BackendSelected
  [ ] SlowPath
  [ ] ServiceMatched
  [ ] VlanDetected
  [ ] PacketAllow

Check the Deny IP ACL rules ICMP:

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl add drop src 192.168.0.0/24:any dst 192.168.0.202:any proto icmp
ACL rule added
added rule Drop: icmp 192.168.0.0:any -> 192.168.0.202:any (prefix_len=304)
root@orangepirv2:~sudo tcpdump -ni end0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on end0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

read log file:

root@orangepirv2:/home/orangepi/ebpf# cat ./test.log 
…
2026-08-13T17:21:35.257433Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545048648274746 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:36.285353Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545049676208365 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:37.313289Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545050704135651 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:38.333321Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545051724172595 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:39.357436Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545052748286770 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:40.381334Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545053772177407 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:41.405289Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545054796140251 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:42.429270Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545055820124679 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T17:21:43.453263Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545056844116064 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0

On the Orange pi R2S itself:

$ ping 192.168.0.202
PING 192.168.0.202 (192.168.0.202) 56(84) bytes of data.
From 192.168.0.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.202)
^C
--- 192.168.0.202 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8196ms

Check TCP using iperf3 (for example, port 80):
On OrangePi RV2:

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl add drop src 192.168.0.0/24:any dst 192.168.0.202:80 proto tcp
ACL rule added

./target/debug/ebpf-ctl acl list
id  plen  fam  src                                dst                                proto sport  dport  rate  action
0   304   4    192.168.0.0                        192.168.0.202                      icmp any    any    -     Drop
1   320   4    192.168.0.0                        192.168.0.202                      tcp  any    80     -     Drop

root@orangepirv2:~# iperf3 -s -p 80
-----------------------------------------------------------
Server listening on 80 (test #1)
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated


root@orangepirv2:/home/orangepi/ebpf# cat ./test.log 
…
src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T17:36:23.293385Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545936684167882 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T17:36:24.317258Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545937708103844 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T17:36:25.341274Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545938732107054 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T17:36:26.365267Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545939756097723 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T17:36:27.389307Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545940780144350 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T17:36:29.405287Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=545942796125120 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=47284 dst_port=80 protocol=TCP aux0=0 aux1=0
root@orangepirv2:/home/orangepi/ebpf#

Naturally, Orange Pi r2s:

root@orangepir2s:/home/orangepi# iperf3 -c 192.168.0.202 -p80
^C- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
iperf3: interrupt - the client has terminated

UDP:

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl add drop src 192.168.0.0/24:any dst 192.168.0.202:80 proto udp
ACL rule added
added rule Drop: udp 192.168.0.0:any -> 192.168.0.202:80 (prefix_len=320)
root@orangepirv2:~# iperf3 -s -p 80 
-----------------------------------------------------------
Server listening on 80 (test #1)
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated

root@orangepirv2:/home/orangepi/ebpf# cat ./test.log 
…
2026-08-13T17:54:34.709969Z  WARN ebpf_daemon::monitoring: Skipping map id 470: Map id 470 is not events ringbuf (name=counters, type=percpu_array)
2026-08-13T17:54:34.763748Z  WARN ebpf_daemon::monitoring: Skipping map id 471: Map id 471 is not events ringbuf (name=event_mask, type=array)
2026-08-13T17:54:34.817658Z  INFO ebpf_daemon::monitoring: Opened events map
2026-08-13T17:54:34.817834Z  INFO ebpf_daemon::monitoring: Events ringbuf size: 16777216 bytes
2026-08-13T17:54:34.825118Z  INFO ebpf_daemon::monitoring: Starting ringbuf event loop
2026-08-13T17:54:50.010419Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=547043401254143 event_kind=PacketDrop ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=59158 dst_port=80 protocol=UDP aux0=0 aux1=0
root@orangepirv2:/home/orangepi/ebpf#

OrangePI R2S:

iperf3 -c 192.168.0.202 -p80 -u
Connecting to host 192.168.0.202, port 80
iperf3: error - unable to read from stream socket: Resource temporarily unavailable
root@orangepir2s:/home/orangepi#

Check the Allow IP ACL. Here we create an allow rule, but for a specific host (with or without a rate limit): Enable logging:

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl event-log enable PacketAllow
enabled event-log: PacketAllow
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl event-log list
event-log mask: 0x102
enabled events:
  [x] PacketDrop
  [ ] RateLimited
  [ ] ConntrackMiss
  [ ] BackendSelected
  [ ] SlowPath
  [ ] ServiceMatched
  [ ] VlanDetected
  [x] PacketAllow

UDP traffic was not tested separately with iperf3 for the allow scenario because an iperf3 UDP test requires an additional TCP connection to control the session.

However, UDP processing at the ACL level was directly verified using a Drop rule. The eBPF logs recorded a packet with protocol=UDP and dst_port=80, after which the packet was dropped.

./target/debug/ebpf-ctl acl add allow src 192.168.0.3:any dst 192.168.0.202:80 proto tcp
ACL rule added
added rule Allow: tcp 192.168.0.3:any -> 192.168.0.202:80 (prefix_len=320)
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl list
id  plen  fam  src                                dst                                proto sport  dport  rate  action
0   304   4    192.168.0.0                        192.168.0.202                      icmp any    any    -     Drop
1   320   4    192.168.0.0                        192.168.0.202                      tcp  any    80     -     Drop
2   320   4    192.168.0.0                        192.168.0.202                      udp  any    80     -     Drop
3   320   4    192.168.0.3                        192.168.0.202                      tcp  any    80     -     Allow

root@orangepirv2:/home/orangepi/ebpf# iperf3 -s -p 80  
-----------------------------------------------------------
Server listening on 80 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.0.3, port 48720
[  5] local 192.168.0.202 port 80 connected to 192.168.0.3 port 48730
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  58.0 MBytes   486 Mbits/sec                  
[  5]   1.00-2.00   sec  59.9 MBytes   502 Mbits/sec                  
[  5]   2.00-3.00   sec  60.1 MBytes   504 Mbits/sec                  
[  5]   3.00-4.00   sec  59.5 MBytes   499 Mbits/sec                  
[  5]   4.00-5.00   sec  58.6 MBytes   492 Mbits/sec                  
[  5]   5.00-6.00   sec  58.5 MBytes   491 Mbits/sec                  
[  5]   6.00-7.00   sec  59.2 MBytes   497 Mbits/sec                  
[  5]   7.00-8.00   sec  60.1 MBytes   504 Mbits/sec                  
[  5]   8.00-9.00   sec  60.2 MBytes   505 Mbits/sec                  
[  5]   9.00-10.00  sec  59.4 MBytes   498 Mbits/sec                  
[  5]  10.00-10.02  sec  1.25 MBytes   510 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.02  sec   595 MBytes   498 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 80 (test #2)
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated

root@orangepirv2:/home/orangepi/ebpf# cat ./test.log | grep "192.168.0.3"
…
2026-08-13T18:24:00.442171Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=548786152157138 event_kind=PacketAllow ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=32988 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T18:24:00.442250Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=548786152166221 event_kind=PacketAllow ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=32988 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T18:24:00.442329Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=548786152174721 event_kind=PacketAllow ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=32988 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T18:24:00.442407Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=548786152184263 event_kind=PacketAllow ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=32988 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T18:24:00.442486Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=548786152192096 event_kind=PacketAllow ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=32988 dst_port=80 protocol=TCP aux0=0 aux1=0
2026-08-13T18:24:00.442565Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=548786152200096 event_kind=PacketAllow ifindex=2 src=192.168.0.3 dst=192.168.0.202 src_port=32988 dst_port=80 protocol=TCP aux0=0 aux1=0

Regarding the rate limit (this will simply be checked via iperf3):

./target/debug/ebpf-ctl acl list
id  plen  fam  src                                dst                                proto sport  dport  rate  action
0   304   4    192.168.0.0                        192.168.0.202                      icmp any    any    -     Drop
1   320   4    192.168.0.0                        192.168.0.202                      tcp  any    80     -     Drop
2   320   4    192.168.0.0                        192.168.0.202                      udp  any    80     -     Drop
3   320   4    192.168.0.3                        192.168.0.202                      tcp  any    80     -     Allow

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl del --id 3
Deleted ACL rule 3
deleted rule id=3

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl add allow src 192.168.0.3:any dst 192.168.0.202:80 proto tcp rate 1
ACL rule added
added rule Allow: tcp 192.168.0.3:any -> 192.168.0.202:80 (prefix_len=320 rate=1)
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl list
id  plen  fam  src                                dst                                proto sport  dport  rate  action
0   304   4    192.168.0.0                        192.168.0.202                      icmp any    any    -     Drop
1   320   4    192.168.0.0                        192.168.0.202                      tcp  any    80     -     Drop
2   320   4    192.168.0.0                        192.168.0.202                      udp  any    80     -     Drop
3   320   4    192.168.0.3                        192.168.0.202                      tcp  any    80     1     Allow
root@orangepirv2:/home/orangepi/ebpf#

According to the tests it will be:

root@orangepirv2:~# iperf3 -s -p 80  
-----------------------------------------------------------
Server listening on 80 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.0.3, port 45004
[  5] local 192.168.0.202 port 80 connected to 192.168.0.3 port 45010
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   256 KBytes  2.09 Mbits/sec                  
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  10.00-10.21  sec   100 KBytes  3.90 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.21  sec   356 KBytes   286 Kbits/sec                  receiver
-----------------------------------------------------------
Server listening on 80 (test #2)
-----------------------------------------------------------

Now let's compare this with the results from the same type of test performed earlier.

4. Testing Deny and Allow with VLAN ACL

For a functional VLAN ACL test, a small isolated setup with two or three nodes is sufficient. A larger test environment with many VLANs, hosts, and policies would be necessary for evaluating dataplane performance and scalability as the number of rules and network segments increases.

The VLAN test was performed on the physical end0 interface. The end0.300 and end0.100.200 VLAN subinterfaces were used for IP configuration and generating test traffic, while the actual VLAN header processing was performed by the XDP program on incoming traffic received through the physical interface.

MikroTik VLAN Configuration

Here is how I configured the VLANs on the MikroTik:

/interface vlan
add interface=bridge0 name=vlan300 vlan-id=300
/ip address
add address=192.168.100.1/24 interface=vlan300

How I configured VLAN on the OrangePi RV2 (I configured it similarly on the R2S):
Standard VLAN:

ip link add link end0 name end0.300 type vlan id 300 ip addr add 192.168.100.2/24 dev end0.300 ip link set end0.300 up

QinQ on Mikrotik:
External tag:

/interface vlan
add interface=bridge0 name=qinq100 vlan-id=100

Internal tag:

interface vlan
add interface=qinq100 name=vlan200 vlan-id=200
/ip address
add address=192.168.200.1/24 interface=vlan200

On orangepi:

ip link add link end0 name end0.100 type vlan id 100 ip link add link end0.100 name end0.100.200 type vlan id 200 ip addr add 192.168.200.2/24 dev end0.100.200
и получаем на orangepi :
6: end0.100@end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c0:74:2b:fa:72:0c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c274:2bff:fefa:720c/64 scope link 
       valid_lft forever preferred_lft forever
7: end0.100.200@end0.100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c0:74:2b:fa:72:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.2/24 scope global end0.100.200
       valid_lft forever preferred_lft forever
    inet6 fe80::c274:2bff:fefa:720c/64 scope link 
       valid_lft forever preferred_lft forever
9: end0.300@end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c0:74:2b:fa:72:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 scope global end0.300
       valid_lft forever preferred_lft forever
    inet6 fe80::c274:2bff:fefa:720c/64 scope link 
       valid_lft forever preferred_lft forever

4.1 Deny VLAN ACL:

For a Clean Test:

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl del --id 0
error: Failed to delete rule: Failed to delete ACL rule
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl list
(l4_acl map is empty)
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl vlan list
(vlan_acl map is empty)

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl event-log list
event-log mask: 0x2
enabled events:
  [x] PacketDrop
  [ ] RateLimited
  [ ] ConntrackMiss
  [ ] BackendSelected
  [ ] SlowPath
  [ ] ServiceMatched
  [ ] VlanDetected
  [ ] PacketAllow

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl event-log enable VlanDetected
enabled event-log: VlanDetected
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl vlan add 300 drop
Added VLAN rule: outer_vlan=300
added vlan rule (outer=300): drop
root@orangepirv2:/home/orangepi/ebpf#

cat ./test.log 
…
src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=300 aux1=1
2026-08-13T19:19:27.799742Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552121190282679 event_kind=PacketDrop ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:19:28.813405Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552122204262459 event_kind=VlanDetected ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=300 aux1=1
2026-08-13T19:19:28.813658Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552122204286126 event_kind=PacketDrop ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:19:29.837427Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552123228281300 event_kind=VlanDetected ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=300 aux1=1
2026-08-13T19:19:29.837677Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552123228302716 event_kind=PacketDrop ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:19:30.861526Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552124252362097 event_kind=VlanDetected ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=300 aux1=1
2026-08-13T19:19:30.861864Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552124252401680 event_kind=PacketDrop ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:19:31.885517Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552125276358813 event_kind=VlanDetected ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=300 aux1=1
2026-08-13T19:19:31.885760Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552125276389521 event_kind=PacketDrop ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:19:32.909459Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552126300305529 event_kind=VlanDetected ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=300 aux1=1
2026-08-13T19:19:32.909704Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552126300335362 event_kind=PacketDrop ifindex=2 src=192.168.100.1 dst=192.168.100.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
root@orangepirv2:/home/orangepi/ebpf#

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl vlan add 100 drop inner 200

2026-08-13T19:21:11.197702Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552224588524734 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:11.198016Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552224588554442 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:21:12.209419Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552225600272714 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:12.209665Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552225600299630 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:21:13.233435Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552226624286596 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:13.233753Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552226624313137 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:21:14.257513Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552227648361060 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:14.257769Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552227648388352 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:21:15.277840Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552228668675580 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:15.278091Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552228668710455 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:21:16.301488Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552229692338134 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:16.301757Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552229692367675 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0
2026-08-13T19:21:17.325564Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552230716399223 event_kind=VlanDetected ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=100 aux1=2
2026-08-13T19:21:17.325825Z  INFO ebpf_daemon::monitoring: eBPF event timestamp_ns=552230716434556 event_kind=PacketDrop ifindex=2 src=192.168.200.1 dst=192.168.200.2 src_port=0 dst_port=0 protocol=ICMP aux0=0 aux1=0

Checking the rate limit on the VLAN:

./target/debug/ebpf-ctl acl vlan add 100 allow inner 200 rate 1
Added VLAN rule: outer_vlan=100
added vlan rule (outer=100 inner=200 rate=1): allow

iperf3 -s -p 80 
-----------------------------------------------------------
Server listening on 80 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.200.3, port 39500
[  5] local 192.168.200.2 port 80 connected to 192.168.200.3 port 39508
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver
-----------------------------------------------------------
Server listening on 80 (test #2)
-----------------------------------------------------------

Check the application of rules from the configuration file:

cat ./config2.yml

acl:
  allow:
    - vlan:
        - 300
        - outer: 200
          inner:
            - 100
            - 101
      rate: 1
    - src:
        addresses:
          - 192.168.0.2/32
          - 192.168.100.0/24
      dst:
        addresses: 192.168.0.202
        ports:
          number: 80
          proto: tcp
      rate: 1

  drop:
    - vlan:
        - 300
        - outer: 130
          inner:
            - 100
    - src:
        addresses:
          - fe80::/64
      dst:
        addresses:
          - fe80::c274:2bff:fefa:720c
        ports:
          number: any
          proto: icmp
      rate: 1
    - src:
        addresses:
          - 10.0.0.0/8
          - 192.168.200.1/24
      dst:
        addresses:
          - 192.168.0.2
        ports:
          number: any
          proto: icmp
      rate: 1

logging:
  PacketDrop: true
  RateLimited: false
  ConntrackMiss: false
  BackendSelected: false
  SlowPath: false
  ServiceMatched: true
  VlanDetected: true
  PacketAllow: false

And this is how Pulsar itself reads it:

cat ./test.log 
2026-08-13T20:11:00.641182Z  INFO ebpf_daemon::manager::maps: rate_limit: global max_tokens=65536, refill_per_sec=64000, per_rule_multiplier=256
2026-08-13T20:11:00.641442Z  INFO ebpf_daemon::manager::maps: monitoring: ringbuf_bytes=16777216, poll_interval_ms=100
2026-08-13T20:11:00.641509Z  INFO ebpf_daemon::manager::maps: acl.default_action: allow
2026-08-13T20:11:00.760323Z  INFO ebpf_daemon::monitoring: Trying XDP program id: 245
2026-08-13T20:11:00.814464Z  INFO ebpf_daemon::monitoring: bpftool prog show id 245: 245: xdp  name xdp_dataplane  tag fa484001870657d5
    loaded_at 2026-08-13T23:09:05+0300  uid 0
    xlated 19776B  jited 9000B  memlock 20480B  map_ids 483,484,485,487,493,492
    btf_id 360
2026-08-13T20:11:00.868271Z  WARN ebpf_daemon::monitoring: Skipping map id 483: Map id 483 is not events ringbuf (name=counters, type=percpu_array)
2026-08-13T20:11:00.922074Z  WARN ebpf_daemon::monitoring: Skipping map id 484: Map id 484 is not events ringbuf (name=event_mask, type=array)
2026-08-13T20:11:00.975972Z  INFO ebpf_daemon::monitoring: Opened events map
2026-08-13T20:11:00.976150Z  INFO ebpf_daemon::monitoring: Events ringbuf size: 16777216 bytes
2026-08-13T20:11:00.983324Z  INFO ebpf_daemon::monitoring: Starting ringbuf event loop

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl list
id  plen  fam  src                                dst                                proto sport  dport  rate  action
0   304   4    10.0.0.0                           192.168.0.2                        icmp any    any    -     Drop
1   320   4    192.168.0.2                        192.168.0.202                      tcp  any    80     1     Allow
2   320   4    192.168.100.0                      192.168.0.202                      tcp  any    80     1     Allow
3   304   4    192.168.200.0                      192.168.0.2                        icmp any    any    -     Drop
4   304   6    fe80:0:0:0:0:0:0:0                 fe80:0:0:0:c274:2bff:fefa:720c     icmp any    any    -     Drop
root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl acl vlan list
id    outer_vlan inner_vlan action   rate  
0     100        101        allow    1     
1     130        100        drop     0     
2     100        200        allow    1     
3     250        -          drop     0     
4     300        -          allow    1

root@orangepirv2:/home/orangepi/ebpf# ./target/debug/ebpf-ctl event-log list
event-log mask: 0xc2
enabled events:
  [x] PacketDrop
  [ ] RateLimited
  [ ] ConntrackMiss
  [ ] BackendSelected
  [ ] SlowPath
  [x] ServiceMatched
  [x] VlanDetected
  [ ] PacketAllow
root@orangepirv2:/home/orangepi/ebpf#

What Still Needs to Be Done
Current Implementation Limitations

At the current stage, the implementation of several events and features related to stateful packet processing is not yet complete:

ConntrackMiss
BackendSelected
SlowPath
ServiceMatched

These features are related to connection state tracking, backend selection, and service traffic processing. They are planned to be implemented at the Traffic Control (TC) layer, where stateful processing will be handled, including conntrack, load balancing, and NAT.
For now, the events listed above are used as placeholders and do not represent fully implemented functionality.
The project is available under an open-source license on GitHub:
https://github.com/AlexRoot00/Pulsar/tree/master

I Bought a Robot Vacuum, Not a Cloud Spy

Alex Root — Mon, 12 Jan 2026 19:21:08 +0000

Background: Buying a Used Robot

I didn’t buy this robot vacuum because I urgently needed automated cleaning.
I bought it used — on purpose.
Buying a brand-new device comes with invisible obligations:

warranty
the mental barrier of “don’t touch it, you might break something”
the expectation that it must “work off its price” before you can experiment.

A new device feels like something you’re borrowing from the manufacturer.
A used device is different.
When hardware is already second-hand, already “imperfect”, you’re free.
You’re not breaking a product — you’re giving it a second life.
This mindset matters a lot for engineering projects.

Why This Model

The robot is a Xiaomi Robot Mop Essential.
On the local market inside my country, I paid $25, including delivery.
A new one costs around $125.
For $25 I got:
a fully functional robotic platform

motors, sensors, MCU, Wi-Fi
something i could open without guilt For $125 I would have gotten the same hardware… plus obligations. The choice was obvious.

Expectations vs Reality

To be clear: this robot does its job well.
It drives. It cleans. It creates internal maps and attempts to send them to the cloud.
It does randomly crash into walls — literally.
The robot builds its maps by:

bumping into obstacles with its bumper
calculating position from wheel encoders
using basic orientation and motion sensors
No LiDAR. No magic. Just contact, math, and retries.

And it works surprisingly well.
The problem was never cleaning quality.
The problem was control.

Mechanical Issues and Repairs

This project didn’t start as reverse engineering.
It started with very practical, very physical problems.

The Wheel Problem

The robot was used, and it showed it.
One of the metal bushings had literally destroyed the plastic seat in the wheel.
Instead of a clean fit, the bushing had “eaten” its way through the plastic, leaving a loose, unusable connection.

My fix was simple but effective:

Lubricate the metal bushing.
Fill the damaged plastic seat with a small tube of cyanoacrylate glue (superglue).
Wait about 2 hours for full curing.
Remove the bushing and reinstall. Result: firm fit, no wobble, wheel restored. This was my first signal: this thing is repairable.

Wet Surface Traction (Unsolved)

One mechanical issue still remains: traction on wet surfaces.
The robot sometimes slips during mopping.

Possible reasons:

insufficient downforce
poor contact area
unsuitable wheel tread design

I’m experimenting with:

different TPU filaments
various 3D-printed tread patterns

Goal: reliable traction without overloading motors.
This problem is open, and that’s fine — some solutions require iteration.

Wet Cleaning System

The water nozzles were clogged.
Fix: a thin needle normally used for cleaning 3D-printer nozzles.

While I was there, I also repaired the small water pump feeding the mop cloth.
No replacement parts, no manuals — just understanding the system.

From Buttons to Control: Where the Real Problem Started

After fixing the mechanical issues, the robot worked… almost.
To start cleaning, I still had to:

walk up to it
press a physical button
watch it desperately try to connect to Wi-Fi
and eventually give up

Factory resets didn’t help.
Creating a fresh Mi Home account didn’t help.
Different phones didn’t help.

The robot wanted Wi-Fi, but it never fully joined.
It built internal maps, sent data to the cloud, and occasionally learned your walls by crashing into them — literally.
At some point, I realized something absurd:

The robot was Wi-Fi enabled, cloud-dependent — and completely unusable without the cloud.
That was the breaking point.
I didn’t buy a robot assistant to turn it into a cloud-controlled spy. I wanted control, not stupid permissions. So I did what any curious engineer would do: I opened it.

Inside the Xiaomi Robot Mop Essential

The robot has a very clear internal hierarchy: two brains.
The Main MCU — The Real Robot
The MCU is the heart of the machine. It’s responsible for everything that actually matters:

Motor control
Wheel encoders
Bump sensors
gyroscope and orientation
navigation logic
map building

Based on available technical data and analysis of similar Xiaomi robots, this MCU typically features:

a 32-bit RISC core for control logic
a dedicated DSP core for real-time sensor processing
hardware blocks optimized for navigation and SLAM-like calculations
external Flash memory for firmware and maps

The MCU doesn’t care about Wi-Fi. It doesn’t know what a cloud is.
It just wants to clean floors.
The ESP32-WROOM — The Permission Relay

The ESP32 module’s job is limited but critical:

Wi-Fi connectivity
communication with Xiaomi cloud
OTA updates
relaying commands and permissions

It does not drive motors.
It does not decide where the robot goes.
It mostly acts as a translator and gatekeeper between the cloud and the real robot.

Listening Instead of Guessing: UART Sniffing
(No photos of how I connected the UARTs from the Orange Pi in MITM mode — I didn’t think they’d be useful at the time.)
To fully understand the system, I connected an Orange Pi RV2 as a man-in-the-middle.
Wiring scheme:
UART5 RX and UART5 TX → MCU
UART7 TX and UART7 RX → ESP32

Why not just an ESP32?

Because I needed three UART ports simultaneously:

MCU → ESP32 communication
ESP32 → MCU communication
MCU diagnostic port (which I connected later, after freeing UART5 while keeping UART7 dedicated to command transmission)

The Orange Pi quietly sniffed all traffic:

no injections
no modifications
just observation

I read both the diagnostic UART and the official ESP32 UART simultaneously in a single terminal window.
This let me see exactly what happened when I sent commands, and compare the robot’s reactions to the actual status updates.

I noticed:
The official UART (ESP32 ↔ MCU) reports only two types of errors:

Incorrect command (command doesn’t apply to this MCU)
Wrong command The diagnostic UART shows much more: motor currents, encoder values, gyro readings, and internal flags. Example diagnostic output when starting cleaning:

Oc[3]=410  Ic[3]=-43  k p=101  
Oc[3]=363  Ic[3]=-58  
p offsg 213  
gyrod=10029  
sg 181  
crc=15fb  
STL start clean  
default map enable:1

Commands sent to the MCU via official UART produce status codes (ok, error…) numerically.
The diagnostic UART shows the robot’s internal response in real time.
What Actually Happens During Startup
Here’s a simplified version of the handshake:

MCU -> ESP32 : platform_name
ESP32 -> MCU : ok
MCU -> ESP32 : firmware_id
ESP32 -> MCU : ok
MCU -> ESP32 : mac_device ?
ESP32 -> MCU : <device_id>
(success handshake)
MCU -> ESP32 : “Can I request OTA updates?”
ESP32 -> MCU : ok
ESP32 can now send commands and listen to response from MCU.
Normal operation begins.
No cryptography. No authentication at this layer. No magic.

This alone tells you everything:
The MCU asks for permission.
The ESP32 simply relays answers from the cloud.
The robot doesn’t talk to the internet - it asks if it’s allowed to.
Replacing the Cloud with My Own ESP32

Once it became clear that the MCU was merely asking for permission from the ESP32, the solution was obvious:
If the original ESP32 only replies “ok” to the MCU… then I can reply “ok” too.
Instead of the original chain:
MCU <-> Xiaomi Cloud <-> App
I wanted:
MCU <-> My ESP32 <-> Optional UI / Terminal / Custom Features
Same expectations. Same protocol.
No cloud. No spying.
The factory ESP32 was removed.
My own ESP32 took its place.
Not to fully emulate the cloud — but to get it out of the way.
Now, the MCU can clean floors, build maps, and respond to commands without ever contacting the internet.

Minimal ESP32 Firmware Architecture.
The firmware I built is modular, with clear responsibilities:
Core system (critical for multitasking and reliability):
dispatcher — task manager
scheduler — time and event scheduling
multicore — leveraging both cores of the ESP32
Hardware & peripherals:
uart — read both diagnostic and official MCU ports simultaneously
ext_flash — work with external SPI flash
display — optional screen for status
buttons & leds — physical interface
Communication & protocols:
miio_miot — simplified implementation of Xiaomi MIOT protocol, enough to relay commands and monitor state
http — web interface for control
auth — authentication for local UI
wifi_mgr — optional Wi-Fi management
Utility & support:

terminal — serial terminal for debugging

logger — log all UART traffic and events
sysinfo — system diagnostics
time_sync — keep time in sync
storage — configuration and map persistence
ota — optional firmware updates(ESP32)

Dual UART Monitoring
One of the key features: reading two UARTs simultaneously.
Official MCU <-> ESP32 UART: status, commands, simple errors
Diagnostic UART: detailed motor currents, encoder readings, gyro data, internal flags
This allowed me to:
verify that commands were correctly interpreted
see detailed internal responses
log all activity for debugging and development
The result is a full local control system, where nothing is hidden behind the cloud.

Current Status

At the moment, the ESP32 firmware is still under development. Most of the core system is functional — about 80% complete.

The modules are in place, dual UART monitoring works, and the dispatcher, scheduler, and multicore systems are running. Basic MIOT-like protocol handling (JSON API) is already implemented.

Some modules, like OTA, are already integrated, which will make future modifications — including connecting the display and enhancing the interface — much easier to implement.

Once finished, the robot will have full local control, reliable telemetry, and optional display feedback — all without ever needing the cloud.

Physical Mods: Replacing Buttons with a “Head”
Original Button Modul

My parallel connection to button / uart to esp32 and diagnostic port

Temporary installation of buttons and LEDs

Once the software and UART control were in place, the next step was physical accessibility.
My NodeMCU board and button cluster couldn’t fit comfortably in the original housing if I wanted to add a display and retain easy access to the interface.
The solution: create a small “tower” or “head” on top of the robot.
What I did
-Relocated the original button block to the new head
-Kept parallel functionality: the robot still responds to factory buttons
-Replaced the original 8 factory LEDs with 2 custom RGB LEDs for clear status indication
Integrated a small display for additional information ( planned for future update)

This physical modification achieves several goals:

Makes interacting with the robot intuitive even without an app
Keeps visual status indicators simple and visible
Allows me to retain full MCU control while optionally using the original buttons

Think of it as a “command tower” — a small cockpit for my robot that gives it a personality and a clear interface.

What I’d Change if Designing This Robot

If I were designing the Xiaomi Robot Mop Essential from scratch, here’s what I would do:
-Provide full local control out of the box, without requiring cloud connection

Make cloud telemetry optional and clearly permission-based
Expose an official UART or API for advanced users
Allow easy replacement or expansion of LEDs and buttons for custom interfaces
Include a modular design for attaching displays or additional sensors

This would let engineers and hobbyists:

Understand what the robot is doing
Customize behavior safely

Avoid turning a simple cleaning robot into an unintended cloud spy.😁