Solaris support issue

[anjog]

Prerequisites

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Issue Details

• Version of AdGuard Home server:
  Latest

• How did you install AdGuard Home:
  Built from source with a patched version of https://github.com/insomniacslk/dhcp interfaces/bindtodevice_bsd.go:
  Added Solaris support otherwise building AdGuardHome fails.
  (sed -i 's/build /build solaris /g' ~/dhcp/interfaces/bindtodevice_bsd.go)

• CPU architecture:
  AMD64

• Operating system and version:
  OmniOS r151036

Expected Behavior

Client receives dns request response

Actual Behavior

Client's (iOS) Browser (Safari) hangs

Screenshots (Logfile)

root@r151036:~/AdGuardHome# ./AdGuardHome
2021/02/28 21:56:15 [info] AdGuard Home, version v0.0.0, channel development, arch solaris amd64
2021/02/28 21:56:15 [error] AutoHosts: FEN based watcher not yet supported for fsnotify

2021/02/28 21:56:15 [info] Initializing auth module: /root/AdGuardHome.bak/data/sessions.db
2021/02/28 21:56:15 [info] Auth: initialized. users:1 sessions:1
2021/02/28 21:56:15 [info] Initialize web module
2021/02/28 21:56:15 [info] AdGuard Home is available on the following addresses:
2021/02/28 21:56:15 [info] Go to http://127.0.0.1:80
2021/02/28 21:56:15 [info] Go to http://127.0.0.1:3001 (BETA)
2021/02/28 21:56:15 [info] Go to http://[::1]:80
2021/02/28 21:56:15 [info] Go to http://[::1]:3001 (BETA)
2021/02/28 21:56:15 [info] Go to http://172.16.0.143:80
2021/02/28 21:56:15 [info] Go to http://172.16.0.143:3001 (BETA)
2021/02/28 21:56:16 [info] Starting the DNS proxy server
2021/02/28 21:56:16 [info] Ratelimit is enabled and set to 20 rps
2021/02/28 21:56:16 [info] The server is configured to refuse ANY requests
2021/02/28 21:56:16 [info] DNS cache is enabled
2021/02/28 21:56:16 [info] MaxGoroutines is set to 300
2021/02/28 21:56:16 [info] Creating the UDP server socket
2021/02/28 21:56:16 [info] Listening to udp://[::]:53
2021/02/28 21:56:16 [info] Creating a TCP server socket
2021/02/28 21:56:16 [info] Listening to tcp://[::]:53
2021/02/28 21:56:16 [info] Entering the UDP listener loop on [::]:53
2021/02/28 21:56:16 [info] Entering the tcp listener loop on [::]:53
2021/02/28 21:56:16 [info] error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:51928: sendmsg: invalid argument
2021/02/28 21:56:16 [info] error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:56826: sendmsg: invalid argument
2021/02/28 21:56:16 [info] error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:53926: sendmsg: invalid argument
2021/02/28 21:56:17 [info] error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:56826: sendmsg: invalid argument
2021/02/28 21:56:17 [info] error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:51928: sendmsg: invalid argument
2021/02/28 21:56:17 [info] error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:53926: sendmsg: invalid argument
...

Additional Information

The udpWrite() error seems to appear in dnsproxy/proxy/Server_udp.go line 125 (proxyutil.UDPWrite).

EDIT: It was just a try building and runnnig AdGuardHome native on Solaris(-fork)-systems. If fixing this error is not an easy task, using a VM/Solaris LX-zone would be an alternative. But hopefully you can provide a simple workaround.

[ainar-g]

Hi. We don't support Solaris or its forks, so we cannot really say what could be wrong. Probably has something to do with differences in support for socket options.

If you want to request AdGuard Home to support Solaris, please file a separate issue, mentioning this and your previous one, and we'll consider it in the future, when we have the resources.

[ainar-g]

Forgot to add. The error message is indeed from our dnsproxy module, but it may be the case that it is not directly reponsible. It could be that there is something with how Go's x/net/ipv4 marshals out-of-bound data or it could be a weird interaction between those modules. Unfortunately, we don't have the time to investigate properly, but PRs are welcome.