[Enhancement] write: broken pipe , (FIN→RST) issue

[MaurUppi]

Improvement Suggestion

Recently, I've been trying to migrate from Surge to Dae. Given that, I set the log_level : trace
There are obvious differences from other logs took my attention. About 10 lines per second, not heavry but wants to get an understanding of what caused the issue.

level=warning msg="handlePkt: write tcp 192.168.1.15:51040->113.x.x.x:12101: write: broken pipe"
level=warning msg="handlePkt: write tcp 192.168.1.15:51040->113.x.x.x:12102: write: broken pipe"
level=warning msg="handlePkt: write tcp 192.168.1.15:57070->113.x.x.x:11106: write: broken pipe"

Therefore, I took a day and worked with Claude to develop a shell script for analysis and confirmation.

Finding in short:

• Peer closed gracefully, dae continued writing → DAE DESIGN ISSUE

RECOMMENDATION:

• dae writes after peer FIN. Implement connection state tracking.

Detailed report

================================================================================
ACCOUNTABILITY ANALYSIS REPORT

Generated: 2026-01-05 16:40:51
Total Events: 104
Analyzed (pcap+strace): 63

================================================================================
CONCLUSION: DAE_DESIGN_ISSUE
CONFIDENCE: MEDIUM-HIGH (69% Scenario A)

EVIDENCE BREAKDOWN:
┌─────────────────────────────────────────────────────────────────────────────┐
│ Scenario A (FIN→RST): 44 events
│ Peer closed gracefully, dae continued writing → DAE DESIGN ISSUE
├─────────────────────────────────────────────────────────────────────────────┤
│ Scenario B (RST only): 0 events
│ Peer reset abruptly without FIN → PEER/NETWORK ISSUE
├─────────────────────────────────────────────────────────────────────────────┤
│ Scenario C (Errors ignored): 0 events
│ dae continued writing after EPIPE → DAE IMPLEMENTATION BUG
├─────────────────────────────────────────────────────────────────────────────┤
│ Proper Handling: 19 events
│ dae handled error correctly → NO ISSUE
└─────────────────────────────────────────────────────────────────────────────┘

RECOMMENDATION:
dae writes after peer FIN. Implement connection state tracking.

DATA SOURCES:
tcpdump: ENABLED (dae-triage-20260105-163625/tcpdump)
strace: ENABLED (dae-triage-20260105-163625/strace)
events: dae-triage-20260105-163625/events.jsonl

Output: dae-triage-20260105-163625

Stopping and generating final analysis...

================================================================================
ACCOUNTABILITY ANALYSIS REPORT

Generated: 2026-01-05 16:40:51
Total Events: 104
Analyzed (pcap+strace): 63

================================================================================
CONCLUSION: DAE_DESIGN_ISSUE
CONFIDENCE: MEDIUM-HIGH (69% Scenario A)

EVIDENCE BREAKDOWN:
┌─────────────────────────────────────────────────────────────────────────────┐
│ Scenario A (FIN→RST): 44 events
│ Peer closed gracefully, dae continued writing → DAE DESIGN ISSUE
├─────────────────────────────────────────────────────────────────────────────┤
│ Scenario B (RST only): 0 events
│ Peer reset abruptly without FIN → PEER/NETWORK ISSUE
├─────────────────────────────────────────────────────────────────────────────┤
│ Scenario C (Errors ignored): 0 events
│ dae continued writing after EPIPE → DAE IMPLEMENTATION BUG
├─────────────────────────────────────────────────────────────────────────────┤
│ Proper Handling: 19 events
│ dae handled error correctly → NO ISSUE
└─────────────────────────────────────────────────────────────────────────────┘

RECOMMENDATION:
dae writes after peer FIN. Implement connection state tracking.

DATA SOURCES:
tcpdump: ENABLED (dae-triage-20260105-163625/tcpdump)
strace: ENABLED (dae-triage-20260105-163625/strace)
events: dae-triage-20260105-163625/events.jsonl

System ENV

uname -a
Linux dae 6.8.0-90-generic #91-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 18 14:14:30 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

dae --version
dae version v1.0.0
go runtime go1.23.9 linux/amd64

cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"
VERSION_CODENAME=noble

The script.

dae_triage_unified_v5.sh
dae_triage_unified_v2_README.md

Potential Benefits

Code owner, please analyze if this is a false alert or true.

IF true, I believe your fix will make dae more robust.

[dae-prow]

Thanks for opening this issue!

[MaurUppi]

@jschwinger233

[MaurUppi]

Here is a summary of the last 24 hours' statistical data.

 50188  113.x.x.x:11106
 33786  113.x.x.x:12102
 13459  113.x.x.x:11104
  6715  113.x.x.x:12101
  1739  113.x.x.x:11102
  1437  113.x.x.x:11103
   577  113.x.x.x:12142
   422  113.x.x.x:11101
   234  113.x.x.x:11142
   207  113.x.x.x:12143
   172  113.x.x.x:11141
    74  113.x.x.x:12141
    17  113.x.x.x:11108

[ppdragon16]

This may have been fixed in the "next" version at https://github.com/lostattractor/dae.

Note: the configuration is incompatible, dial_mode is replaced with dial_target_override, reroute_mode and sniff_verify_mode.

[MaurUppi]

This may have been fixed in the "next" version at https://github.com/lostattractor/dae.

Note: the configuration is incompatible, dial_mode is replaced with dial_target_override, reroute_mode and sniff_verify_mode.

Thanks for the updates.

• What version # of the "next" ver would be, and when it will be released?
• For the configuration changed part, it seems it will be implemented accordingly, so is there an updated document that can be read yet?

[ppdragon16]

• What version # of the "next" ver would be, and when it will be released?
• For the configuration changed part, it seems it will be implemented accordingly, so is there an updated document that can be read yet?

"next" has no release version. I compile it myself. Unfortunately there is no document for the configuration.

defaults:
dial_target_override: true
reroute_mode: 'while_needed'
sniff_verify_mode: 'loose'

dial_mode: ip -> dial_target_override: false
dial_mode: domain -> defaults
dial_mode: domain+ -> sniff_verify_mode: 'none'
dial_mode: domain++ -> sniff_verify_mode: 'none' & reroute_mode:' force'

Note: "next" doesn't support some protocols, e.g. vless/vmess/juicity/tuic/etc.

[MaurUppi]

Can you give me more detailed info about dial_target_override: true and reroute_mode: 'while_needed', such as what feature both is provided?

Would it be possible to run the script that I provide, so that it may help to confirm IF your version fixed the potential issue?

Furthermore, how can I try your build?