[Bug Report] 在发起请求的设备上如果设置了 hosts，dae 会嗅探失败

[EkkoG]

Checks

• I have searched the existing issues
• I have read the documentation
• Is it your first time sumbitting an issue

Current Behavior

发现在发起请求的设备上如果设置了 hosts，dae 会嗅探失败

Expected Behavior

正常嗅探到域名，且在 domain++ 模式下重新路由流量

Steps to Reproduce

1. 在主路由上运行 daed, 在发起请求的设备上配置 hosts，并用这个域名发起请求

Environment

• Dae version (use dae --version): 0.6.0rc2
• OS (e.g cat /etc/os-release): ImmortalWrt 23.05.1
• Kernel (e.g. uname -a): Linux ImmortalWrt 5.15.137 #0 SMP Sun Nov 19 17:02:49 2023 x86_64 GNU/Linux
• Others:

Anything else?

在主路由上抓了一下包显示请求的 SNI 是正常的，日志显示没有嗅探到域名，看了一下没有什么针对嗅探的配置，所以应该是一个 bug？ 还是说因为设置的 hosts 导致 DNS 不经过 dae 所以嗅探失败了，粗略看了一下代码是有从 TLS 握手包中获取 SNI 的逻辑的，但是没有深入看，所以不知道是不是这个原因导致的

日志如下

root@ImmortalWrt:~# tail -f /var/log//daed/daed.log | grep 45.32.113.xxx
time="Aug 22 12:01:07" level=info msg="192.168.33.120:51518 <-> 45.32.113.xxx:443" dialer="1.新加坡 IEPL [03] [Std]" dscp=0 ip="45.32.113.xxx:443" mac="00:11:32:88:b0:01" network=tcp4 outbound=proxy pid=0 pname= policy=min_moving_avg sniffed=
time="Aug 22 12:01:18" level=info msg="192.168.33.120:51575 <-> 45.32.113.xxx:443" dialer="1.新加坡 IEPL [03] [Std]" dscp=0 ip="45.32.113.xxx:443" mac="00:11:32:88:b0:01" network=tcp4 outbound=proxy pid=0 pname= policy=min_moving_avg sniffed=

b.pcap.zip

路由器上抓包数据见压缩包

[dae-prow]

Thanks for opening this issue!

[EkkoG]

修改 嗅探超时 (ms) 为 200 后比较稳定的能成功了

root@ImmortalWrt:~# ping 192.168.33.120
PING 192.168.33.120 (192.168.33.120): 56 data bytes
64 bytes from 192.168.33.120: seq=0 ttl=64 time=0.967 ms
64 bytes from 192.168.33.120: seq=1 ttl=64 time=1.273 ms
64 bytes from 192.168.33.120: seq=2 ttl=64 time=1.006 ms
64 bytes from 192.168.33.120: seq=3 ttl=64 time=1.127 ms
64 bytes from 192.168.33.120: seq=4 ttl=64 time=1.132 ms
64 bytes from 192.168.33.120: seq=5 ttl=64 time=0.955 ms
64 bytes from 192.168.33.120: seq=6 ttl=64 time=0.783 ms
^C
--- 192.168.33.120 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 0.783/1.034/1.273 ms

这个延时应该不算高吧？需要调整到 200 这么大才可以吗

[mzz2017]

@EkkoG 什么情况下要调高嗅探超时还不明确，之前查明是tcp握手之后的首包接收较慢导致，但未能找到根因。当时的案例重启无法解决，重装 linux 系统解决

[EkkoG]

刚好现在有可以复现的场景，是否需要获取更多环境的信息来找根本的原因？或者需不需要跑什么测试代码

[mzz2017]

@EkkoG 可以帮忙在各个链路抓包看看，是慢在哪一环了