gluon-wan-dnsmasq not resolving due to needing CAP_NET_RAW for libpacketmark.so

[benzea]

There is a dnsmasq instance running on port 54 to handle WAN DNS requests. To correctly route them, the outgoing socket should use setsockopt(SO_MARK) set using the libpacketmark.so preload library. However, setting SO_MARK requires CAP_NET_RAW (or CAP_NET_ADMIN).

dnsmasq does the right thing and drops the capability unless they are needed. As gluon-wan-dnsmasq does not use DHCP, etc. it doesn't actually keep the required capability. As such, the libpacketmark.so setsockopt fails with -EPERM and the wrong routing table may be used (in upstream gluon this will affect IPv6, in the parker fork it also affects IPv4).

Possible solutions:

• Use network namespaces (likely infeasible in the short term)
• Use VRFs instead of packet marking for routing purposes
• Make dnsmasq keep the privileges:
  • Simple workaround is to pass a dummy --enable-ubus=gluon-wan-dnsmasq parameter, as the capabilities are kept then
  • Patching dnsmasq could be an option
  • A hook in libpacketmark.so to set the capabilities seems like it would be very fragile at best

[neocturne]

Decision from meetup:

• For 2025.1, we will implement one of the mentioned workarounds
• For 2026.1, a VRF will be used

[neocturne]

The --enable-ubus workaround is probably the least invasive, only resulting in the following syslog messages once on start (as the ujail prevents the ubus connection):

daemon.info dnsmasq[1]: UBus support enabled: bus connection pending
daemon.err dnsmasq[1]: Cannot set UBus listeners: no connection