Given that the ISC DHCP software is on it's way out of OpenWRT I wonder what people's thoughts here on enabling the DHCP relay (BUSYBOX_DEFAULT_DHCPRELAY) feature in busybox.
brianjmurrell,
Ain't OpenWrt using odhcpd ? https://openwrt.org/docs/techref/odhcpd
Together with dnsmasq, https://openwrt.org/docs/guide-user/dhcp/dhcp_configuration
So why enable busybox DHCP relay?
DG.
Ain't OpenWrt using odhcpd ? https://openwrt.org/docs/techref/odhcpd
That's orthogonal to DHCP relay.
But if you want to use other software packages as examples, OpenWrt is already using the BusyBox udhcpc client. So why not the relay also?
Together with dnsmasq, https://openwrt.org/docs/guide-user/dhcp/dhcp_configuration
Which is a big beast with lots of configuration knobs and switches that need adjusting in order to make it do (only) the simple task of DHCP relay, particularly when you don't need dnsmasq otherwise (i..e DHCP and DNS are being done elsewhere in the network).
So why enable busybox DHCP relay?
Most importantly is size, which is incredibly important in embedded environments. Also simply alternatives and choice. There are lots of alternatives available in OpenWRT. Why should DHCP relay not also provide choices and alternatives. One choice doesn't always fit all circumstances.
But to turn the question around, why not enable BusyBox's DHCP relay? It's a simple configuration switch to enable it and then people get choice again, which they have right now with the ISC DHCP relay, but that choice is about to come to an end.
It seems appropriate to re-instate choice by providing an alternative in the situation where an alternative is being taken away.
If BusyBox is good enough to provide a DHCP client, why not a DHCP relay also?
brianjmurrell,
To reduce memory usage it could be a good alternative.
But if this -for example- uses more CPU% (or bus-timing), there could be devices having trouble with it.
I am not that familiar with DHCP, mostly I use what OpenWrt supports, but trying something else is never prohibited 
Why not try it yourself and inform OpenWrt development about the results?
DG.
But if this -for example- uses more CPU% (or bus-timing), there could be devices having trouble with it.
But why assume such things? And in the remote case where it is, why decide for others which is more import for them? Give them the choice and let them make it themselves.
Why not try it yourself and inform OpenWrt development about the results?
Because I'm not really kitted out do to source builds and it's not a trivial process to get there. I use the imagebuilder to build my firmwares. It would be orders of magnitude less effort for one of the main developers to make a single line switch change than it would take for me to get kitted up to do source builds.