dnsproxy on mips / mipsle issues

[rskallies]

A follow up from AdguardTeam/AdGuardHome#3778

I'm unable to use dnsproxy on mips / mipsle platform because it does not work with encrypted upstreams when Adguard Home is used as upstream, either selfhosted or dns.adguard.com.

The specific device is an GL.iNet E750 mobile router which is using a MIPS 24 Kc SoC. But the issue can be reproduced even on an Qemu emulated mipsel machine running in a Docker environment https://hub.docker.com/r/asmimproved/qemu-mips/

How to reproduce:

1. create self signed SSL cert / pem only for testing on emulated local machine
2. Install latest dnsproxy mipsel release
3. Launch dnsproxy as follows, dnsproxy will listen for QUIC requests on port 8888

./dnsproxy --insecure -c certs/server.pem -k certs/server.key -l 127.0.0.1 -q 8888 -u dns://1.1.1.1 -v -p 5354

4. Lauch another dnsproxy on the same machine which will be used as client for the server launched in step 3 demonstrating the issue:

./dnsproxy --insecure -u quic://127.0.0.1:8888 -p 6666 -v

5. run dig on the machine:

dig @127.0.0.1 -p 6666 heise.de

see the debug output:

2021/12/17 18:03:46 22100#32 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): error handling DNS (udp) request: talking to dnsUpstream failed, cause: failed to open QUIC session to quic://127.0.0.1:8888, cause: timeout: no recent network activity 2021/12/17 18:03:46 22100#38 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): Dialing to 127.0.0.1:8888 2021/12/17 18:03:46 22100#38 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): dialer has successfully initialized connection to 127.0.0.1:8888 in 3.950558ms 2021/12/17 18:03:47 22100#38 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): Dialing to 127.0.0.1:8888 2021/12/17 18:03:47 22100#38 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): dialer has successfully initialized connection to 127.0.0.1:8888 in 953.054µs 2021/12/17 18:03:48 22100#38 [debug] time.Duration.Milliseconds(): upstream quic://127.0.0.1:8888 failed to exchange ;heise.de. IN A in 3.360159924s. Cause: failed to open QUIC session to quic://127.0.0.1:8888, cause: timeout: no recent network activity 2021/12/17 18:03:48 22100#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).replyFromUpstream(): RTT: 3.362456568s 2021/12/17 18:03:48 22100#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: SERVFAIL, id: 17816 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
So even on a loopback device on the MIPS / MIPSLE platform I'm unable to use DoQ or DoT.
Using dnsproxy with an external upstream is also not working when using a Adguard Home instance as upstream and either DoQ or DoT

DoT does work with dnsproxy on this platform using other DoT providers like tls://1.1.1.1:853 but not with tls://dns.adguard.com:853

Doing the same tests as above on other platforms like x86_64 or arm64 does work like a charm. No issues using crypto with upstreams.

[ameshkov]

@ainar-g
Most likely the issue needs to be reported to https://github.com/lucas-clemente/quic-go

We'll need to come up with a simple reproducer for it since it's not specified to DNS.

[rskallies]

I build their example https://github.com/lucas-clemente/quic-go/blob/master/example/echo/echo.go and tested it on mips, it does not work either:

root@GL-E750:~# ./echo 
panic: timeout: no recent network activity

goroutine 1 [running]:
main.main()
	./echo.go:30 +0x84

build on darwin/amd64 works out of the box:

./echo
Client: Sending 'foobar'
Server: Got 'foobar'
Client: Got 'foobar'

[ameshkov]

Apparently, there will be no fix for that: quic-go/quic-go#3302 (comment)