Many, many thanks, tempestuous, for pursuing the "autodhcp" problem I reported. I have examined the documentation at the link you included and understand why the change was made and what it is intended to accomplish. I will review what I understand and opine (as a former corporate programmer on mission-critical ealtime satellite control systems).
This DHCP client supports the DHCPv4 specifications which have been updated to be compatible with the newer DHCPv6 specs. This impacts the "clientID" that is transmitted to "the network" (router, in my case). The controlling documents, RFC 2131 & RFC 2132 have been updated to delete some options in the composition of the clientID, specifically the use of the network interface MAC address alone; it can be combined with other data as a client ID, but in a format that does not begin with the MAC address.
In the real world, and acknowledged in the RFC documents, some networking equipment (e.g. D-Link DI-524) work only with the MAC address form of ClientID -- or at least their user interface expects them. The devices operate under firmware control; so updates to comply with the modified requirements depend on each manufacturer releasing a firmware upgrade -- very unlikely for older units.
All of the man pages I could find (up to 3.0.19) state that if a clientID is not specified (as in Puppy), the default is the MAC address. The 2.17/3.00 version, 3.1.0 (and probably earlier), changes the default that all software relies on, without notifying anyone (that I could find) of the impact of the change in default -- or that it has changed! This secretive revision of the rules was frowned upon in my programming environment, to put it mildly.
However, I see the desirablity of adapting to the new requirements. The benefit I see for Puppy users is that a PC or laptop that has both an NIC and a wireless card (or either built in) would be recognized on a network as the same computer and IP address; currently, each interface on that computer would have a separate IP address and appear as a separate computer. (Another issue the changes address is the fact that an IP address is associated with a NIC or wireless card that could be moved to another computer, instead of continuing to associate the IP address with the computer. This is important in sophisticated networks where the IP address is associated with other characteristics of the particular computer's place in the network configuration; changing out a NIC upsets this.)
In the recommendations for implementing "node-specific identification" of networked equipment, the burden appears to be placed on the client (Puppy, through dhcpcd) to ensure that only one "clientID" is issued by a computer-&-operating system (I think). If a PC has multiple network interfaces, it must use the same ID on all interfaces; this means additional logic either in Puppy or dhcpcd. The dhcpcd developer has not (AFAIK) announced what DHCPCD does about this or expects from the invoker. I suspect that Puppy will have to build a ClientID somehow and pass it as the "-I ..." option to dhcpcd; or it will have to read the ID that dhcpcd creates (but has not been described, or how to read it) and save and re-use it for all subsequent invocations.
With that as background, I feel that, for now, Puppy must ensure that nothing changes in what it uses to identify PCs. I have tested the recommendation to use "-I ''" and it appears to work; my test entailed inserting that parameter into the script net-setup.sh invocation of dhcpcd.
Although the new parameter restores the expected behavior, so would reverting to the old version (1.3.22) or the Slackware version (2.0.4) of dhcpcd. However, 3.1.0 seems to have other bugs that I reported in the beta2 thread. Both 2.0.4 and 3.1.0 give false positives for a not-completely-connected interface; but ifconfig shows different consequences of that -- 2.0.4 shows no eth0 link (good), while 3.1.0 results in an "active" link using IP address 169.254.184.245 (at least on my system) that causes the browser to (frustratingly) not find any web sites (bad). What is a newbie to do!
The conservative action for 3.00 final would be to revert to 1.3.22 and wait until next release to implement compliance with the ClientID requirements of 3.1.0, whatever they turn out to be, and/or to correct the false-positive problem. Are there any compelling reasons for jumping to 3.1.0 ahead of all mainstream Linux distributions?
FYI, I see that the developer web site may be
http://dhcpcd.berlios.de/, but I could not get it to load.
Thanks, again, for initiating the dialog with the developer.
Richard