The gentoo RC scripts (/lib/rcscripts/net/udhcpc.sh in baselayout-1 and /lib/rc/net/udhcpc.sh in baselayout-2) call udhcpc using the --env option. Busybox' udhcpc does not support this option. Currently, busybox cannot be used as a dhcp client on a Gentoo system. The attached patch adds the --env option and makes busybox work as a udhcpc replacement. The udhcp ebuild has the same patch, in fact, the attached patch is fully based on /usr/portage/net-misc/udhcp/files/udhcp-0.9.9_pre20041216-env.patch. The only changes are to account for busybox' different getopt and memory implementations. I understand that this patch for the udhcpc ebuild will stay in portage because it was not accepted upstream. I expect the same will go for this patch, so I'm filing this report here instead of upstream.
Created attachment 140670 [details, diff] Patch against 1.7.4 Patch was tested with 1.7.4. Also applies and compiles with 1.8.2, running was not tested.
Please send this patch upstream. Should make it a configurable option also.
I explicitely reported this bug here and not upstream. I found the original reference, which was from [1] # Setup options for the udhcpc script # This requires a specfic Gentoo patch to udhcp which will not # be accepted upstream. Also, seeing that the equivalent patch to udhcpc (which essentially has the same codebase as busybox, and AFAIK the same maintainers) is also in Portage as a patch instead of upstream since april 2006, I think the place for this patch is in Gentoo. However, since I can't seem to find any reference on busybox' and udhcp's bugtrackers, I'll see what upstream thinks of this patch. [1]: http://archive.netbsd.se/?ml=gentoo-embedded&a=2007-10&m=5404844
I second the addition of this patch. It's already considered acceptable for udhcpc so it should pass the smell test to do the same patch for busybox If upstream ever accept the patch already offered then great - in the meantime though lets not have half just half the ebuilds patched. Basically if it's patched in one then I can't see any reason not to patch it for both ebuilds?
(In reply to comment #0) > The gentoo RC scripts (/lib/rcscripts/net/udhcpc.sh in baselayout-1 and > /lib/rc/net/udhcpc.sh in baselayout-2) call udhcpc using the --env option. Shouldn't those RC scripts be patched not to use this option? I imagine that's harder, but seems the correct way to do it. :P
It's been a while since I looked at this code, so I can't really recall why the --env option is needed at all. I would agree that not using this option would be favorable (that would also allow the --env patch to be removed from the udhcp ebuild). However, I'm afraid that there is no other elegant way to solve whatever --env is trying to solve with existing udhcpc options. On the other hand, it's also not unlikely that this was just the first working solution and initially the --env patch was expected to be accepted upstream as well. I can look into this a bit closer, but that won't be anytime soon. Also, I'm really not familiar with Gentoo, so fiddling around with internals like baselayout might not work out so great for me :-)
This has become more important now because the standalone udhcp package has been masked.
(In reply to comment #2) > Please send this patch upstream. Should make it a configurable option also. > - net-misc/udhcp-0.9.9_pre20041216-r4 (masked by: package.mask) /usr/portage/profiles/package.mask: # Diego Pettenò <flameeyes@gentoo.org> (23 Dec 2008) # Mask these for removal, busybox provides those already, and are # unmaintained. As requested by solar. Why do you request masking and removal of this package while you know that busybox is NOT compatible to the stand alone udhcp ebuild?! The Gentoo installation manual explicitly listed udhcp as an alternative for smaller systems and I did choose it therefor on purpose. Now I tried to just unmerge udhcp, since the message sounded as if busybox will just do the job "out of the box", but it doesn't. Would you please stop marking packages for removal and commiting changes to portage BEFORE a proper solution is around?! Thanks...
It's also worth noting that the udhcp package provides a DHCP server, which busybox doesn't. I'm using dnsmasq for a server instead so I'm not too bothered but some people may want this server.
Current udhcpc in busybox has some new options (-O|--request-option), maybe it can be used to replace --env. At least it can be configured not to request DNS, NTP, routers from server. However, /lib/rcscripts/net/udhcpc.sh also use --env to set to interface metric. I think patches for busybox is not strictly required since the udhcpc hook script can read configurations from /etc/conf.d/net. In other words, read the extra configurations in /lib/rcscript/sh/udhcpc.sh instead of /lib/rcscript/bin/udhcpc.sh. BTW, /lib/rcscript/sh/udhcpc.sh is a part of net-misc/udhcp, which is masked for removal. But busybox isn't shipped with it..., as busybox is a member of "system" set. Shouldn't it be the default dhcp client for baselayout?
Created attachment 177461 [details] busybox dhcp module, put into /lib/rcscripts/net
Created attachment 177462 [details] busybox's udhcpc hook script, put into /lib/rcscripts/sh
(In reply to comment #9) > It's also worth noting that the udhcp package provides a DHCP server, which > busybox doesn't. I'm using dnsmasq for a server instead so I'm not too bothered > but some people may want this server. busybox has the server, but the official portage tree disables it by default. I add two attachments, it works with current busybox without patches. This stuff is likely existed before, since there are some codes remains in current baselayout. Even it created temporary files, but I think it not so bad. to test this stuff add something like this in /etc/conf.d/net modules=( "busybox" ) config_eth0=( "dhcp" ) busybox_eth0="..." # extra options passed to busybox udhcpc
> to test this stuff > add something like this in /etc/conf.d/net > > modules=( "busybox" ) > config_eth0=( "dhcp" ) > busybox_eth0="..." # extra options passed to busybox udhcpc I wanted to test the stuff, unmerged udhcp an used the two files you provided. I put the first two config lines into my net config. I did not get any errors, but I also did not get any IP address, sadly. But thanks for your effort!
(In reply to comment #14) > I wanted to test the stuff, unmerged udhcp an used the two files you provided. > I put the first two config lines into my net config. I did not get any errors, > but I also did not get any IP address, sadly. But thanks for your effort! hmm, it's so bad. I tested with baselayout-1.12.11.1 and busybox-1.12.2-r1 without problems. You say you didn't get errors, it's quite strange. May be you could turn on verbose output for /etc/init.d/net.*, it will report what modules is used.
jackieku, you need to redo those for more recent versions. baselayout-2 is very different, primarily because it uses OpenRC. The scripts now go in /lib/rc and bash has been dropped in favour of sh.
(In reply to comment #16) > jackieku, you need to redo those for more recent versions. baselayout-2 is very > different, primarily because it uses OpenRC. The scripts now go in /lib/rc and > bash has been dropped in favour of sh. It's sound so bad, I really like bash. :) And I really don't like update to baselayout-2 now until it is stabilized (it seems downgrade back to baselayout-1 needs a lot of works). Anyway, I'll try in a VM, thank for you hints. PS. Does it mean all script in /etc/init.d can not written in bash? so sad...
It's not as bad as it sounds but I'm not going to get into that debate! I'd be lying if I said I hadn't had a couple of issues with OpenRC but I do like it overall and it's blazingly fast. Not sure about the other init.d scripts but I think that may be the case.
Created attachment 177485 [details] /lib/rc/net/busybox.sh for baselayout-2
I added another attachment for baselayout-2, which uses the same udhcpc.sh file, but it should be placed in /lib/rc/sh instead. There are some options for passing extra options from /etc/conf.d/net to udhcpc hook script. First, we can create temporary as the attachments. Second, just do "source /etc/conf.d/net" in udhcpc.sh, thank for baselayout-2, it even doesn't need bash. The last option is patching busybox as someone does before, in my opinion, it should be worst choice. I have no idea about which one should be used, discussion required.
That works for me. Note that you have to make udhcpc.sh executable or it won't work.
Ok, shame on me! I was too utterly stupid to make those shell scripts executable... After chmodding them it works as intended! Thanks for the files and the advice!
Why isnt this in portage yet? I just installed a new system and omitted any dhcp package because I thought this method would be the default.... But no, it still isn't! Please include these files in baselayout and make busybox the default fallback dhcp and a lot of people will love you. Thanks PS: I tried this with baselayout2 and it just works.
base-system.. Please look over this bug.
Dear dudes and dudesses. This bug is now quite old and patches have been provided. If I remember correctly, udhcpcd was taken out of the tree with busybox as the suggested replacement. What's up here? This is a situation where every stage3 ships with a perfectly adequate DHCP client, yet the official docs suggest manually and redundantly installing something as basic, just because already written patches to have it actually work are never commited. The absurdity of it all struck me recently when carelessly removing networkmanager temporarely left me without a functioning DHCP client. 'Wait,' i thunk, 'what about busybox's?' - and so to this bug. If DHCP can be made to work out of the box without wasting a single byte, why isnt it already?
It would be nice to get this sorted before baselayout-2 is marked stable, which should be happening soon.
(In reply to comment #25) > Dear dudes and dudesses. This bug is now quite old and patches have been > provided. If I remember correctly, udhcpcd was taken out of the tree with > busybox as the suggested replacement. What's up here? > > This is a situation where every stage3 ships with a perfectly adequate DHCP > client, yet the official docs suggest manually and redundantly installing > something as basic, just because already written patches to have it actually > work are never commited. > The absurdity of it all struck me recently when carelessly removing > networkmanager temporarely left me without a functioning DHCP client. 'Wait,' i > thunk, 'what about busybox's?' - and so to this bug. If DHCP can be made to > work out of the box without wasting a single byte, why isnt it already? > Yes, totally agreed. FIVE MONTH AGO, I did not have the patience to write it down in this polite manner anymore. Now, for crying out loud, is it possible that somebody takes some action and just copies the files needed to the appropriate package, PLEASE? This just adds a feature almost everybody wants, it does not add any dangerous behaviour or eats kittens... Those who do not want this can still add a static ip manually, why this procrastination?! And to the other people on the CC list: maybe it helps if you vote for this bug. Thanks
This is beyond ridiculous, people... At least give _some_ form of explaination as to what exactly is wrong with the proposed patches, that keeps them from being applied.
solar, Matthijs: Matthijs said he mailed upstream about it, but the link he provided no longer works. Did upstream reject the busybox patch, and if so, why? Alternatively, did it just get dropped and lost? Matthijs: Can you please update your patch for the latest busybox?
I've never actually mailed upstream about the patch I think. I did ask on IRC, but never got a meaninful reply. I think the link I gave in my first comment was to this post: http://www.mail-archive.com/gentoo-embedded@lists.gentoo.org/msg02029.html Which contains a comment that implies that udhcp's upstream had already rejected the patch. Anyway, I don't have any Gentoo systems running anymore, so I won't be able to invest more work in this report. If anyone else wants to test and possibly update the patch, or contact upstream (seems busybox and udhcpc have the same upstream developers?), feel free to do so. Btw, after rereading all the comments in this report it seems jackieku created an alternative solution that doesn't require patching busybox / udhcpc. Perhaps that's a better approach? Seem Comment #10 and comment #20.
NO PATCHING NEEDED! With jackieku's solution. Just copy the *.sh to the correct places and instant dhcp is avaiable in Gentoo OOB. As the previous poster wrote (and i omitted in my earlier rantings, sorry for that), it is all done with https://bugs.gentoo.org/show_bug.cgi?id=205286#c10 and https://bugs.gentoo.org/show_bug.cgi?id=205286#c20 To repeat it in other words: All you need to add are two scripts to the system (with different versions of busybox.sh for the different baselayouts!). NO PATCHING, no talk to upstream, no problem. I tested it on 32bit systems with baselayout-1 and -2, also I use it currently on my amd64 system with baselayout-2. I just stumbled over it again on a VM install of Gentoo... PS: busybox does not need to be patched in order to get this working, only two simple scripts!
I'd really like to see that, dhcpcd does not handle --request correctly and fails to keep my IP, what I'd need to busybox udhcpc which I failed to have working corretly with Gentoo's networking. Then I searched and found this bug which makes me think it is patched for 2 years but not yet pulled... what a waste...
nice to know that a fix to a bug that's over 3 and half years old is still not applied as of yet....
actually, as it turns out, you also need to add the sample.* files from busybox tarball (e.g. busybox-1.18/examples/udhcpc/sample.*) to /lib/rcscripts/sh/ and rename them all to udhcpc.* before this works...otherwise, the address never actually gets bound to the interface
(In reply to comment #34) > actually, as it turns out, you also need to add the sample.* files from busybox > tarball (e.g. busybox-1.18/examples/udhcpc/sample.*) to /lib/rcscripts/sh/ and > rename them all to udhcpc.* before this works...otherwise, the address never > actually gets bound to the interface What about putting them, say, in /usr/share/busybox/udhcpc? I think that is a better location since they are part of the busybox package and not part of openrc. Can you do that and attach the module with those modifications?
Created attachment 270243 [details] busybox's udhcpc hook script This is the script which actuality configure the network interface, nameservers, and routes, which is called by udhcpc. The default path of this script is /usr/share/udhcpc/default.script. (see busybox udhcpc --help)
Created attachment 270247 [details] /lib/rc/net/busybox.sh for baselayout-2 Do not use /lib/rc/sh.
I may be able to encorporate the hook script directly into openrc after all, let me take a look and I'll report back on this bug.
Created attachment 270817 [details] udhcpc.sh I don't think we need a separate module for busybox since udhcpc doesn't exist now in favor of the busybox applet, so I took your busybox.sh module and used it as a template to update the udhcpc module. Also, your hook script will be encorporated into openrc as ${RC_LIBEXECDIR}/rc/udhcpc-hook.sh. Can you please do the following: 1) remove your busybox.sh module and replace the udhcpc module with this one. 2) put the hook script in the appropriate location. 3) Test and make sure this setup works. Also, I would prefer not to use temporary files, so can you please explain what changes I need to make to the module and the hook script so that this is not necessary? Thanks, William
(In reply to comment #39) > Also, I would prefer not to use temporary files, so can you please > explain what changes I need to make to the module and the hook script so > that this is not necessary? As I explained in comment #10, that will require you make the udhcpc hook script can know the magic (PEER_DNR, PEER_NTP, etc) of openrc by itself without the temporary files. Perhaps by parsing the /etc/conf.d/net or some functions provided by openrc that I don't know (I'm not openrc expert). But I didn't think of there may be a inconsistent issue when I made the comment #10. As the user may modify /etc/conf.d/net after udhcpc start but before the hook script is called, and the hook script will be called by udhcpc multiple times. Our old way is patching udhcpc, but the patch has been reject by upstream IIRC.
Commit b712a91 fixes the udhcpc support in openrc to work with busybox udhcpc. This will be included in openrc-0.8.3.
