ifupdown-0.8.2 / dhcp-4.1-ESV-R12 incompatibility

Hi All,

I'm using SYSVINIT and get the following at startup from S40network:

--8<---
Starting network...
Internet Systems Consortium DHCP Client 4.1-ESV-R12 Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Usage: dhclient [-4|-6] [-SNTP1dvrx] [-nw] [-p <port>]
[-s server-addr] [-cf config-file] [-lf lease-file] [-pf pid-file] [--no-pid] [-e VAR=val] [-sf script-file] [interface]

If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help.

If you did get this software from ftp.isc.org and have not yet read the README, please read it before requesting help. If you intend to request help from the dhcp-bugs at isc.org mailing list, please read the section on the README about submitting bug reports and requests for help.

Please do not under any circumstances send requests for help directly to the authors of this software - please send them to the appropriate mailing list as described in the README file.

exiting.
Failed to bring up eth0.
--8<---

Looking into it, ifupdown-0.8.2 calls dhclient with -I and -df options; these options are not supported by dhclient. The previous version of ifupdown, 0.7.49, worked with dhcp-4.1-ESV-R12. Has anyone else noticed this?

It appears that dhcp-4.3.3 supports the -I and -df options used by ifupdown-0.8.2. Cross-compiling dhcp-4.3.3 will be more complicated since there is now a bind tar-ball embedded into the dhcp source. Is anyone else attempting to add dhcp-4.3.3 to Buildroot?

Thanks and Regards,
...doug

It appears that dhcp-4.3.3 supports the -I and -df options used by ifupdown-0.8.2. Cross-compiling dhcp-4.3.3 will be more complicated since there is now a bind tar-ball embedded into the dhcp source. Is anyone else attempting to add dhcp-4.3.3 to Buildroot?

I had started to look into this a few months ago, and setting --with-libbind=PATH to use the bind provided by Buildroot seemed to be a better option (in order to avoid possibly installing two instances of bind on the target, either standalone or inside the dhcp binaries if statically linked, and both bind versions were compatible at that time), though I have not yet tested it.

Quoted 6 lines · Beno?t Th?baudeau

I had started to look into this a few months ago, and setting --with-libbind=PATH to use the bind provided by Buildroot seemed to be a better option (in order to avoid possibly installing two instances of bind on the target, either standalone or inside the dhcp binaries if statically linked, and both bind versions were compatible at that time), though I have not yet tested it.

Hi Beno?t.
Let me save you some time, it doesn't work as expected.
I've tried pointing that into the bind build directory (because it needs some specific *.a files that i think aren't installed, besides another problem) but no luck, since it stills expects that to live in it's own build directory, try in dhcp's source dir:

find . -name Makefile.am -exec grep --with-filename ../bind/lib {} \;

...and you'll see the drastic results.

Even so with that fixed the bind package will need to get tweaked as well, since if you build shared-only you won't get those intermediate libraries built, and hence dhcp will fail as well.

All in all, it seems pretty broken.

Quoted 24 lines · Gustavo Zacarias

Quoted 6 lines · Beno?t Th?baudeau

I had started to look into this a few months ago, and setting --with-libbind=PATH to use the bind provided by Buildroot seemed to be a better option (in order to avoid possibly installing two instances of bind on the target, either standalone or inside the dhcp binaries if statically linked, and both bind versions were compatible at that time), though I have not yet tested it.

Hi Beno?t.
Let me save you some time, it doesn't work as expected.
I've tried pointing that into the bind build directory (because it needs some specific *.a files that i think aren't installed, besides another problem) but no luck, since it stills expects that to live in it's own build directory, try in dhcp's source dir:

find . -name Makefile.am -exec grep --with-filename ../bind/lib {} \;

...and you'll see the drastic results.

Even so with that fixed the bind package will need to get tweaked as well, since if you build shared-only you won't get those intermediate libraries built, and hence dhcp will fail as well.

Quoted 1 line

All in all, it seems pretty broken.

Given this brokenness, and that there are better alternatives, perhaps we
should kill the dhcp package? Or is it useful as a server? In the latter case, we should add a warning to the ifupdown help text.

BTW, I guess busybox ifupdown does work?

A few months ago, 4.1-ESV-R12 had an EoL date set to Dec. 2015 on
https://www.isc.org/downloads/, but now it is TBA. It probably means that they did not have a chance to finalize the deprecation of 4.1 in Dec. 2015, and that they are rescheduling it, but that it will come soon. Also, several distributions like Ubuntu have already switched to 4.3.x, and this version seems to fix the ifupdown 0.8.2 issue according to what has been previously said in this thread. Regarding the build, Gustavo has said above that it is broken with a bind external to the dhcp package, but it should hopefully work fine with the built-in bind.

All in all, we should probably bump the version to 4.3.3 rather than killing this package.

Best regards,
Beno?t