OpenWrt/LEDE Project

  • Status New
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority High
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Kevin 'ldir' Darbyshire-Bryant - 18.06.2019

FS#2328 - Allocate resources to sort out odhcpd/dnsmasq interaction once and for all.

As IPv6 is being adopted, increasingly people are seeing dnsmasq log ‘spam’. See https://bugs.openwrt.org/index.php?do=details&task_id=1492&string=1492&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

By default under openwrt, dhcpv4 leases are handled by dnsmasq whilst dhcpv6/RA is handled by openwrt’s odhcpd.

odhcpd could handle both v4 & v6 but does not yet have the same configuration flexibility for dhcp options as dnsmasq. I guess this is why no one has been brave enough to switch to odhcpd for ipv4 operations as well as ipv6.

dnsmasq can also handle dhcpv6/RA but not quite as flexibly as odhcpd. dnsmasq will automatically find IP6 prefixes on interfaces and start handling them, whilst openwrt’s strategy with odhcpd is to only handle stuff we tell you to handle, don’t do it automagically.

As dnsmasq is the default resolver for openwrt and the wider LAN, it needs to know about DHCP/hostname allocations. For DHCPv4 this is easy, dnsmasq is controlling them. For DHCPv6 a hosts file (called a statefile in the odhcpd code) is handed to dnsmasq.

By default this host file is not read dynamically, so odhcpd has to signal dnsmasq to re-read the host file (and clear caches etc etc) upon every ipv6 lease change.

This generates a lot of log spam and process startup overhead. There are also questions about service operability during this time.

Effort needs to be put into sorting this out.

Temporary workarounds:

Use ‘hostsdir’ dnsmasq option instead of ‘addn-hosts’ - dnsmasq will dynamically scan changes/additions to hosts in hostsdir whereas addn-hosts needs a SIGHUP. Host deletions cannot be handled by this method, so odhcpd would still need to SIGHUP on lease expiry. It might reduce some of the spam.

Longer term:

Teach dnsmasq to accept hostname updates over an IPC mechanism. ubus? and carry on using odhcpd for ipv6.

Teach dnsmasq to handle ipv6 prefix additions/deletions/handling via an IPC mechanism in the same way as odhcpd. Drop odhcpd and use dnsmasq for everything.

Use odhcpd for everything and use another dns resolver that interfaces nicely with odhcpd.

Why don’t I see this problem: I use dnsmasq to handle ipv6 but I’m lucky enough that this works for me.

This needs fixing/funding to sort it out though.

n8v8R commented on 18.06.2019 14:19

*** no one has been brave enough to switch to odhcpd for ipv4 operations as well as ipv6.

Actually, I do and mostly being satisfied but do concur that it probably needs some maturity to match dsmasq on configuration flexibility for dhcp options.

There is probably no need to retire dnsmasq as dns resolver, be it just for its simplicity in configuration compared to knot or unbound (though admittedly being a fan of the latter), but switch dhcp management entirely to odhcpd (which I am also a fan of) but end the hybrid construct (one way or another).

supersebbo commented on 19.06.2019 13:53

There is a potential exploit impact of the current setup. Reloading host files can take a significant amount of resources when large host files are used for applications such as AdBlock.

It would be trivial to craft a exploit to flood DHCPv6 packets to an OpenWRT router at a rate that meant it became IO blocked.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing