升级到5.2.3或5.2.4后，juicessh、vlc/kodi访问nfs不正常

[shixudong2020]

shadowsocks升级到5.2.3或5.2.4后，JuiceSSH通过SS访问远端ssh服务器，第一次总是提醒“connection error（1005）：Socket error：Connection retset by peer 你想重试吗？”，一般重试一次后即正常，偶尔需要重试多次。而vlc/kodi通过SS则干脆无法访问nfs服务器。在使用5.2.2时，无上述异常现象，升级到5.2.3或5.2.4后，出现上述异常，卸载并重新安装5.2.2后，能恢复正常。why？

[vevsvevs]

Same here.

[shixudong2020]

经反复测试，终于找到bug所在了。ss服务器使用域名就会出现上述问题，改为ip后就一切正常。我是在家里搭了一个SS服务器，家里的公网IP经常会变，所以搞了一个ddns。估计是5.2.3修改ddns相关程序时改出问题来了。
注：我没有使用插件。

[Mygod]

Fill out the bug template.

[shixudong2020]

Describe the bug
ss服务器使用域名，ss升级到5.2.3或5.2.4后，JuiceSSH通过ss访问远端ssh服务器，第一次总是提醒“connection error（1005）：Socket error：Connection retset by peer 你想重试吗？”，一般重试一次后即正常，偶尔需要重试多次。而vlc/kodi通过ss则干脆无法访问nfs服务器。在使用5.2.2时，无上述异常现象，升级到5.2.3或5.2.4后，出现上述异常，卸载并重新安装5.2.2后，能恢复正常。如ss服务器改用ip地址，使用5.2.3或5.2.4也正常。

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

• Android/Chrome OS version: [e.g. "7.0.0_r14" or "71.0.3578.94 (32-bit)", more detailed description is preferred]
• Device: [e.g. Google Pixel XL]
• Version: [e.g. version code "v3.0.0" or commit ID "a073f85"]
• Last version that did not exhibit the issue: [not applicable]

Configuration
Put an x inside the [ ] that applies.

• [ x] IPv4 server address
• IPv6 server address
• [x ] Client IPv4 availability
• Client IPv6 availability
• Encrypt method:chacha20-ietf-poly1305
• Route
  • All
  • Bypass LAN
  • Bypass China
  • Bypass LAN & China
  • GFW List
  • China List
  • [x ] Custom rules
• IPv6 route
• Apps VPN mode
  • Bypass mode
• Remote DNS: 8.8.8.8
• DNS over UDP
• Plugin configuration (if applicable):
• Auto Connect
• TCP Fast Open
• If you're not using VPN mode, please supply more details here:

Additional context
Add any other context about the problem here.

[Mygod]

Fill out the full form.

[Mygod]

Furthermore, are you using Android private DNS? What DNS do you have configured?

[madeye]

@zonyitoo What's the default timeout of shadowsocks-rust's internal DNS resolver?

This issue looks related to the DDNS provider's resolving performance, causing DNS timeout.

[Mygod]

@madeye From my testing, the local DNS result seems cached by the system but it might not be the case on some ROM.

[shixudong2020]

Furthermore, are you using Android private DNS? What DNS do you have configured?

手机没有root，无论使用4G还是wifi，全是自动获取dns，5.2.2(含)以前ss服务器使用域名访问一直正常。而且，ss的ddns域名指向的ip基本不变化，除非家里宽带猫重启。
手机是华为mate 20 pro（android 10），使用另外一台mate 9（android 9），两台手机现象一致。

[zonyitoo]

https://github.com/shadowsocks/shadowsocks-rust/blob/19bc88bcb92ce6f227add410c92d5b40abe5e969/crates/shadowsocks-service/src/local/dns/server.rs#L459

5 seconds.

[shixudong2020]

还是有一点没有想明白，5.2.2(含)以前版本通过域名访问ss服务器就一切正常，但ss客户端启动时，因为ss客户端还没有连通ss服务端，此时，对ss服务器域名的解析应该也是本地解析吧，为何5.2.2(含)以前版本就正常，5.2.3/5.2.4就出现异常呀？还有5.2.3/5.2.4下，JuiceSSH通过SS访问远端ssh 域名服务器，一般选择重试后就正常，而退出JuiceSSH后重新访问，又重复出现上述现象，至于浏览器通过ss访问，目前没有感觉异常。

[Mygod]

fill out the full template or else

[Mygod]

Ok I can reproduce this now. Let me look into it.

[madeye]

Guess it's related to the DNS timeout in shadowsocks-rust.

[Mygod]

I am seeing a lot of ERROR udp relay 127.0.0.1:44537 -> 74.125.195.95:443 (proxied) with 1350 bytes, error: dns resolve <ss host:port> error: resolve empty.

[Mygod]

Also io error: Broken pipe (os error 32). Maybe too many open files?

[madeye]

Can we force using local resolver for thess-host?

Also io error: Broken pipe (os error 32). Maybe too many open files?

It's possible if we keep getting UDP requests.

[Mygod]

I think that is the current behavior.

[Mygod]

local_dns_path seems to always return the correct result despite libsslocal complaining. @zonyitoo Any idea?

Another thing I noticed is that every time a connection is made, AAAA is queried twice to local_dns_path. Why is this?

[Mygod]

@madeye @zonyitoo I will leave this one to you guys as the Android part seems to be responding correctly. 😛

[madeye]

Hmm, but I cannot reproduce the issue locally. Can you enlarge the 5 sec timeout and try again?

[Mygod]

It seems you need a large number of concurrent connections to trigger the issue. local_dns_path responds instantly since the results are cached by the system, so no timeout issue here.

[madeye]

If so, we may remove the cache from unix_stream lookup here: https://github.com/shadowsocks/shadowsocks-rust/blob/0b1630d1c6abcec3861b1eec39b266e1dad206e5/crates/shadowsocks-service/src/local/dns/client_cache.rs#L129

[Mygod]

Yes. In fact I don't think the cache is working since local_dns_path is receiving 3 queries every time a new connection is made. Also caching in ss-rust is a terrible idea: shadowsocks/shadowsocks-rust#345 (comment)

[madeye]

It looks shadowsocks-rust only cached the socket, not the results. I think @zonyitoo just wants to reuse the socket to the local resolver.

[Mygod]

I am pretty sure my implementation does not permit connection reuse. 🤔

[madeye]

Okay, I think we found the issue here.

[Mygod]

🤔 I don't think you can ever assume connection reuse to work for DNS, maybe except for UDP.

[Mygod]

Also local_dns_path does receive 3 valid queries for every connection, so I do not think what you said is the issue.

[shixudong2020]

我估计与5.23的Refined DDNS support有关，但最让我不解的是，如前一贴所述：5.2.2(含)以前版本通过域名访问ss服务器一切正常，但ss客户端启动时，因为ss客户端还没有连通ss服务端，此时，对ss服务器域名的解析也需要本地解析，为何5.2.2(含)以前版本就正常，5.2.3/5.2.4就出现异常呀！

[madeye]

Please try again with this APK: https://drive.google.com/file/d/1OMgPLhiLoU0_b9lTYWfOvp6SMqO7kk8_/view?usp=sharing

It disables the connection reuse for unix stream lookup.

@Mygod @shixudong2020

[shixudong2020]

这个版本正常了，难道5.2.2处理SS服务器域名时没有使用connection reuse for unix stream lookup？

[madeye]

这个版本正常了，难道5.2.2处理SS服务器域名时没有使用connection reuse for unix stream lookup？

Right, we don't have this before 5.2.3.

[Mygod]

@madeye Push the changes to a PR and I will test?

[madeye]

See shadowsocks/shadowsocks-rust#567

[Mygod]

Fixed via 247c4a1 I suppose.