dhcpcd now manages routing in a sane manner across multiple interfaces on BSD. It always has on Linux due to it’s route metric support, but as BSD doesn’t have this it’s a little more tricky. We basically maintain a routing table built from all the DHCP options per interface and change it accordingly. As such, dhcpcd now prefers wired over wireless and changes back to wireless if the cable is removed (assuming both on the same subnet) and this works really well :DIt’s now starting to look quite stable and all the features in dhcpcd-4 appear to be working still so I’ve released an experimental version to get some feedback.
You tag something with a metric. The same somethings with a lower metric take precedence over the same somethings with a higher metric.
dhcpcd has been able to apply metrics to routes on Linux so that we can prefer to route packets over wired instead of wireless. dhcpcd-git is now able to distinguish wired from wireless and can make a metric accordingly.
But how do we teach configuration files about this?
Well, support for multiple instances in dhcpcd is coming along nicely, but I’ve had to pretty much re-write the entire state handling code. The existing code was wait for data or timeout. Then drop into case statements depending on if we timed out and what our current state is.The new code is now based around an event loop, where we register functions to call when we get data or a time has passed.
sed is a very powerful tool. Small than awk and grep and much more powerful. Some would also say it’s harder to use, but I like it :)
Whilst putting a mini resolvconf into dhcpcd, I use very similar code to what I already had. But, I ran into a wall- dhcpcd needs to work when /usr is not mounted as it may be network mounted later. On Gentoo and most Linux distros, sed is found in /bin.
/etc/resolv.conf is a single file that is often stamped on by many different applications. One example of this is dhcpcd running on multiple interfaces. openresolv is a resolvconf implementation to help ahem resolve this by taking resolv.confs from these applications to make a single sane file.dhcpcd has always supported resolvconf when available - but what if it’s not? dhcpcd restores the last saved resolv.conf when it fails/exits to try and make things work, but it’s not exactly optimal as the order interfaces go down may not be the same order as when they come up.
Roy's Blog