Skip to content
This repository has been archived by the owner on Jan 4, 2024. It is now read-only.

DNS issue on Android 13 Beta 1 #457

Closed
iKirby opened this issue May 6, 2022 · 9 comments
Closed

DNS issue on Android 13 Beta 1 #457

iKirby opened this issue May 6, 2022 · 9 comments
Labels
bug Something isn't working

Comments

@iKirby
Copy link

iKirby commented May 6, 2022

Describe the bug

On Android 13 Beta 1, DNS lookup may be slow or completely not work. It happens very frequently when using mobile network, making the app almost unusable.

To Reproduce

  1. Update device to Android 13 Beta 1
  2. Open SagerNet, enable logging and start service
  3. Start browsing internet, sometimes it's OK and sometimes not
  4. When it's working well, switch to mobile network, then DNS will fail for domains that are in bypass list

Also observed some crashes when testing.

Debug Information

You can see DNS errors and crashes in this log
SagerNet 18538973749076878.log

DNS errors:

app/dns: failed write query to dns server DOT//dns.google > context deadline exceeded
app/dns: failed write query to dns server DOT//dns.google > io: read/write on closed pipe

All DNS requests failed.

--

This one was captured when DNS was working and switched to mobile network
SagerNet 6738847959404517672.log

It contains some different DNS errors:

app/dns: failed write query to dns server DOTL//dot.pub > no such process

NOTE: at this time, DNS requests going through proxy was still working

Expected behavior

DNS service works well.

Smartphone (please complete the following information)

  • Kernel version: 4.19.224-g69fd8651238b-ab8268307
  • Device: Pixel 5
  • OS: Android 13 Beta 1

Additional context

There is no problem on a device running Android 12. SagerNet also works well on my old device running Android 7.1.2.

@nekohasekai
Copy link
Member

Disable Private DNS temporarily

@nekohasekai nekohasekai added the bug Something isn't working label May 6, 2022
@iKirby
Copy link
Author

iKirby commented May 7, 2022

Thanks for the reply.
Sorry I forgot to mention that Private DNS was already turned off because it causes problems with another proxy app I use. I just tested setting it to automatic, and results are the same. I can help testing if you need.

@iKirby
Copy link
Author

iKirby commented May 7, 2022

It seems that DNS failure on mobile network is an Android issue. I checked system logcat, there were a lot DnsResolver logs.

DnsResolver: resNetworkResult:android.system.ErrnoException: resNetworkResult failed: ESRCH (No such process)

Also did some testing with Shadowsocks app. When on mobile network, the behavior was the same with the following error.

DnsResolver: resNetworkResult:android.system.ErrnoException: resNetworkResult failed: ESRCH (No such process)
LocalDnsWorker$accept: java.io.IOException: android.net.DnsResolver$DnsException: android.system.ErrnoException: resNetworkResult failed: ESRCH (No such process)
LocalDnsWorker$accept:         (Coroutine boundary)
LocalDnsWorker$accept:         at com.github.shadowsocks.bg.LocalDnsWorker$accept$1.invokeSuspend(LocalDnsWorker.kt:33)
LocalDnsWorker$accept: Caused by: java.io.IOException: android.net.DnsResolver$DnsException: android.system.ErrnoException: resNetworkResult failed: ESRCH (No such process)
LocalDnsWorker$accept:         at com.github.shadowsocks.net.DnsResolverCompat$DnsResolverCompat29$resolveRaw$2$2.onError(DnsResolverCompat.kt:172)
LocalDnsWorker$accept:         at android.net.DnsResolver.lambda$registerFDListener$8(DnsResolver.java:508)
LocalDnsWorker$accept:         at android.net.DnsResolver$$ExternalSyntheticLambda10.run(Unknown Source:8)
LocalDnsWorker$accept:         at com.github.shadowsocks.net.DnsResolverCompat$DnsResolverCompat29.execute(DnsResolverCompat.kt:146)
LocalDnsWorker$accept:         at android.net.DnsResolver.lambda$registerFDListener$9(DnsResolver.java:493)
LocalDnsWorker$accept:         at android.net.DnsResolver$$ExternalSyntheticLambda2.onFileDescriptorEvents(Unknown Source:12)
LocalDnsWorker$accept:         at android.os.MessageQueue.dispatchEvents(MessageQueue.java:293)
LocalDnsWorker$accept:         at android.os.MessageQueue.nativePollOnce(Native Method)
LocalDnsWorker$accept:         at android.os.MessageQueue.next(MessageQueue.java:335)
LocalDnsWorker$accept:         at android.os.Looper.loopOnce(Looper.java:161)
LocalDnsWorker$accept:         at android.os.Looper.loop(Looper.java:288)
LocalDnsWorker$accept:         at android.app.ActivityThread.main(ActivityThread.java:7844)
LocalDnsWorker$accept:         at java.lang.reflect.Method.invoke(Native Method)
LocalDnsWorker$accept:         at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
LocalDnsWorker$accept:         at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
LocalDnsWorker$accept: Caused by: android.net.DnsResolver$DnsException: android.system.ErrnoException: resNetworkResult failed: ESRCH (No such process)
LocalDnsWorker$accept:         ... 14 more
LocalDnsWorker$accept: Caused by: android.system.ErrnoException: resNetworkResult failed: ESRCH (No such process)
LocalDnsWorker$accept:         at android.net.NetworkUtils.resNetworkResult(Native Method)
LocalDnsWorker$accept:         at android.net.DnsResolver.lambda$registerFDListener$8(DnsResolver.java:501)
LocalDnsWorker$accept:         ... 13 more

EDIT: Reported to Google. https://issuetracker.google.com/issues/231691473

@iKirby
Copy link
Author

iKirby commented May 7, 2022

Just found that setting Direct DNS to a simple DNS server (for example 119.29.29.29) solves the issue. But SagerNet still uses the old IP address for connecting to the DNS server after switching network, causing DNS requests to fail. Restarting service fixes the problem. SagerNet should reestablish the connection when switching network.

Start service on Wi-Fi, everything works. Then switch to mobile network, DNS will fail for domains in bypass list.

libcore : updated network type: data
...
v2ray-core: proxy/dns: ip query > app/dns: failed write query to dns server UDPL//119.29.29.29 > write udp 192.168.*.*(My WLAN IP):43655->119.29.29.29:53: sendto: network is unreachable

Start service on mobile network, then switch to Wi-Fi.

libcore : updated network type: wifi
...
v2ray-core: proxy/dns: ip query > app/dns: failed write query to dns server UDPL//119.29.29.29 > write udp 10.92.*.*(Mobile network IP):37377->119.29.29.29:53: sendto: network is unreachable

@iKirby
Copy link
Author

iKirby commented May 8, 2022

OK I've found a workaround for this issue.

Simply use DoH or DoT IP as Direct DNS, to prevent using system resolver to get the IP.

UDP DNS has issues when switching network (see the previous comment).

EDIT: removed incorrect statement.

@nekohasekai
Copy link
Member

You should use tls+local://1.12.12.12 instead of tls://1.12.12.12

@nekohasekai
Copy link
Member

nekohasekai commented May 8, 2022

I can't reproduce these problems in TPB1.220310.029 in DSU and android emulator, maybe it' s device related

@iKirby
Copy link
Author

iKirby commented May 8, 2022

Thanks for the reply. Misunderstood what local means before.

Did a few more testing, and now I'm sure there is something wrong with my mobile network. Don't know why but it seems that my ISP blocked access to 1.12.12.12:853, 120.53.53.53 works.

Sorry about my previous comment, I will edit it.

I tested on Pixel 5 again and I can reproduce the issue caused by switching network when using UDP DNS as direct DNS.

As for the system resolver issue, it might be related to Google Play system update, so it might not be reproducible on emulator image. Last year there was a problematic Google Play system update, which made all network traffic not going through VPN service.

@iKirby
Copy link
Author

iKirby commented Jun 1, 2022

This should be an Android issue, so I'm closing this issue now. I'm sorry for the trouble. Thanks.

@iKirby iKirby closed this as completed Jun 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants