Checks
Current Behavior
When enabling both mwan3 (Dual WAN load balancing) and daed on ImmortalWrt (which strictly uses nftables and fw4), a severe low-level routing conflict occurs, ultimately leading to complete network disconnections.
The core issue stems from the architectural clash between eBPF and Netfilter:
mwan3 heavily relies on traditional Linux Netfilter (nftables) to mark packets (fwmark) and route them through specific policy routing tables (Table 1 for WAN1, Table 2 for WAN2).
daed hooks into the Linux kernel at the Socket/TC level using eBPF, hijacking and redirecting traffic before or bypassing the standard Netfilter chains.
Because eBPF bypasses or interferes with fw4's strict lifecycle management and mwan3's tagging mechanism, the ICMP/UDP health-check packets sent by mwan3 to monitor WAN status frequently fail to route correctly, even when static routes are manually assigned.
As a result, mwan3 falsely detects WAN offline events and triggers frequent hotplug scripts, forcefully reloading the firewall and routing tables.
This continuous underlying routing "earthquake" abruptly terminates the TCP/UDP connections currently maintained by daed's BPF maps.
At this point, the daed log gets flooded with:
level=warning msg="handlePkt: failed to read DNS resp payload length: io: read/write on closed pipe"
level=warning msg="handlePkt: use of closed network connection"
level=warning msg="handleConn: handleTCP relay error: websocket: close 1000 (normal)"
This creates a death loop: daed intercepts -> mwan3 tracking fails -> mwan3 reloads firewall -> daed connections are killed -> local network drops.
Relevant Logs
1. ImmortalWrt System Log (mwan3 false offline detection & hotplug trigger)
```text
user.info: mwan3track[20866]: Check (ping) failed for target "223.5.5.5" on interface Charlie (pppoe-Charlie). Current score: 3
user.notice: mwan3track[20866]: Interface Charlie (pppoe-Charlie) is offline
user.notice: mwan3-hotplug[30786]: Execute disconnected event on interface Charlie (pppoe-Charlie)
...
user.notice: mwan3track[20866]: Interface Charlie (pppoe-Charlie) is connecting
user.notice: mwan3track[20866]: Interface Charlie (pppoe-Charlie) is online
user.notice: mwan3-hotplug[30985]: Execute connected event on interface Charlie (pppoe-Charlie)
user.notice: firewall: Reloading firewall due to ifup of Charlie (pppoe-Charlie)
*(Note: With daed active, mwan3 continuously fails to ping the tracking IP despite static routes being set. This falsely triggers offline/online hotplug events and massive nftables/fw4 reloads.)*
</details>
<details>
<summary><b>2. daed Error Log (Connections killed directly caused by mwan3 hotplug)</b></summary>
```text
level=warning msg="handlePkt: failed to read DNS resp payload length: read tcp 172.16.212.39:45802->161.33.177.2:49457: use of closed network connection"
level=warning msg="handlePkt: use of closed network connection"
level=warning msg="handlePkt: failed to read DNS resp payload length: io: read/write on closed pipe"
level=warning msg="handlePkt: read udp [::]:41112: i/o timeout"
level=warning msg="handleConn: failed to dial 142.250.197.138:443: dial tcp <nil>->142.250.197.138:443: i/o timeout"
level=warning msg="handleConn: handleTCP relay error: websocket: close 1000 (normal): websocket: close sent"
(Note: Immediately following the fw4 firewall reload triggered by mwan3, daed encounters massive pipe closures, read/write failures, and connection timeouts, completely breaking the local network proxy traffic.)
Expected Behavior
daed should gracefully coexist with policy routing setups based on Netfilter fwmark (like mwan3).
Ideally, there should be an architectural enhancement or a configuration mechanism in daed that allows specific local traffic (such as multi-WAN ICMP/UDP health-check packets) to completely bypass the eBPF hooks and be handed back to the kernel's standard Netfilter routing table, preventing the load balancer from falsely triggering offline hotplug events.
Steps to Reproduce
Install ImmortalWrt with fw4 and configure two active WAN interfaces via PPPoE.
Setup mwan3 to load balance between the two WANs and track external IPs (e.g., 223.5.5.5 and 119.29.29.29).
Install and run daed.
Observe the mwan3 status. It will frequently mark interfaces as disconnected due to ping failures.
Check the daed logs; it will be flooded with use of closed network connection right after mwan3 triggers an interface hotplug reload.
Environment
OS: ImmortalWrt 25.12.1 (Kernel 6.12.x)
Firewall: fw4 / nftables
Multi-WAN Manager: mwan3 (Dual PPPoE configuration)
daed version: Latest
Anything else?
No response
Checks
Current Behavior
When enabling both mwan3 (Dual WAN load balancing) and daed on ImmortalWrt (which strictly uses nftables and fw4), a severe low-level routing conflict occurs, ultimately leading to complete network disconnections.
The core issue stems from the architectural clash between eBPF and Netfilter:
mwan3 heavily relies on traditional Linux Netfilter (nftables) to mark packets (fwmark) and route them through specific policy routing tables (Table 1 for WAN1, Table 2 for WAN2).
daed hooks into the Linux kernel at the Socket/TC level using eBPF, hijacking and redirecting traffic before or bypassing the standard Netfilter chains.
Because eBPF bypasses or interferes with fw4's strict lifecycle management and mwan3's tagging mechanism, the ICMP/UDP health-check packets sent by mwan3 to monitor WAN status frequently fail to route correctly, even when static routes are manually assigned.
As a result, mwan3 falsely detects WAN offline events and triggers frequent hotplug scripts, forcefully reloading the firewall and routing tables.
This continuous underlying routing "earthquake" abruptly terminates the TCP/UDP connections currently maintained by daed's BPF maps.
At this point, the daed log gets flooded with:
level=warning msg="handlePkt: failed to read DNS resp payload length: io: read/write on closed pipe"
level=warning msg="handlePkt: use of closed network connection"
level=warning msg="handleConn: handleTCP relay error: websocket: close 1000 (normal)"
This creates a death loop: daed intercepts -> mwan3 tracking fails -> mwan3 reloads firewall -> daed connections are killed -> local network drops.
Relevant Logs
1. ImmortalWrt System Log (mwan3 false offline detection & hotplug trigger)
```text user.info: mwan3track[20866]: Check (ping) failed for target "223.5.5.5" on interface Charlie (pppoe-Charlie). Current score: 3 user.notice: mwan3track[20866]: Interface Charlie (pppoe-Charlie) is offline user.notice: mwan3-hotplug[30786]: Execute disconnected event on interface Charlie (pppoe-Charlie) ... user.notice: mwan3track[20866]: Interface Charlie (pppoe-Charlie) is connecting user.notice: mwan3track[20866]: Interface Charlie (pppoe-Charlie) is online user.notice: mwan3-hotplug[30985]: Execute connected event on interface Charlie (pppoe-Charlie) user.notice: firewall: Reloading firewall due to ifup of Charlie (pppoe-Charlie)(Note: Immediately following the fw4 firewall reload triggered by mwan3, daed encounters massive pipe closures, read/write failures, and connection timeouts, completely breaking the local network proxy traffic.)
Expected Behavior
daed should gracefully coexist with policy routing setups based on Netfilter fwmark (like mwan3).
Ideally, there should be an architectural enhancement or a configuration mechanism in daed that allows specific local traffic (such as multi-WAN ICMP/UDP health-check packets) to completely bypass the eBPF hooks and be handed back to the kernel's standard Netfilter routing table, preventing the load balancer from falsely triggering offline hotplug events.
Steps to Reproduce
Install ImmortalWrt with fw4 and configure two active WAN interfaces via PPPoE.
Setup mwan3 to load balance between the two WANs and track external IPs (e.g., 223.5.5.5 and 119.29.29.29).
Install and run daed.
Observe the mwan3 status. It will frequently mark interfaces as disconnected due to ping failures.
Check the daed logs; it will be flooded with use of closed network connection right after mwan3 triggers an interface hotplug reload.
Environment
OS: ImmortalWrt 25.12.1 (Kernel 6.12.x)
Firewall: fw4 / nftables
Multi-WAN Manager: mwan3 (Dual PPPoE configuration)
daed version: Latest
Anything else?
No response