Peter Memishian wrote: >... > 2. Leave the old DLPI-based code in the DHCP client, and only use the > sockets-based approach when obtaining leases on IPMP IP interfaces > (which can't use DLPI). This would limit the impact of the use of > the BROADCAST bit to IPMP usage cases, but means that we have two > distinct codepaths to maintain and test in the DHCP client, rather > than simplifying the code -- and all to handle a corner case. > >
The other approach for using DLPI is to open each of the devices that the IPMP interface has been created upon and monitor changes to the set of IPMP interfaces and adjust devices opened via DLPI accordingly. I'll throw another monkey into the ring: with DHCP using DLPI, it doesn't interact at all with IPFilter. Changing DHCP to not use DLPI will alter this relationship, so much so that people who are using DHCP today with IPFilter might find it not working in the future because the packets are blocked. The way it works today is consistent with other platforms, such as BSD, that use BPF for DHCP and thus also bypass IPFilter. Darren
