I have written some extensions to my net.eth* scripts. a) dhcpcd backgrounding: When $dhcpcd_IFACE ends in &, dhcpcd is started in background. b) dhcp and ifconfig: When $dhcpcd_IFACE is set, dhcpcd is startet even when the interface was set up using ifconfig. This allows to use a static default configuration if no DHCP is available while still using DHCP if it is available. c) iwconfig: When $iwconfig_IFACE is set, the device is configured using iwconfig before. d) HWaddr-based configuration: If a file /etc/conf.d/net.01-23-45-67-89-AB exists for an interface with HWaddr 01:23:45:67:89:AB, this file is used for configuration instead of variables set in /etc/conf.d/net. The variable names are kept simple, without the _IFACE. $iface_IFACE becomes $ifconfig. If is also possible to specify $gateway in such a file, or $gateway_IFACE in net for consistency. Setting $iface_IFACE="skip" in net allows an interface to be ignored unless it has a known HWaddr. Reproducible: Always Steps to Reproduce: Examples from my usage where I needed those changes: a) dhcpcd backgrounding: I often have no network connection. I want any existing connection to be detected automatically without slowing down my boot process. b) dhcp and ifconfig: I use my notebook in different environments. In one I have a fixed network address, in the others there are DHCP servers. Using ifconfig to bring up the network with static configuration and later starting dhcpcd should do the magic. c) iwconfig: I want my configuration in one place, so this is rather obvious. d) HWaddr-based configuration: As I have a second NIC in my port replicator, network device names change depending on environment. Now I have $iface_eth1=skip and $iface_eth2=skip in /etc/conf.d/net and two specifig configurations for the NIC in the port replicator as well as for my PCMCIA WLAN (that is eth1 or eth2 depending on situation).
Created attachment 32636 [details, diff] Patch for net.eth0 against baselayout-1.8.6.13
The iwconfig part of this extension is related to bug#16649 and bug#25742. I'm not sure if people want one variable for every likely parameter to iwconfig (like in /etc/pcmcia/iwconfig.opts) or rather all parameters in one variable the way it is now. I perfer one single variable.
Created attachment 32813 [details, diff] Patch against baselayout-1.9.4-r1 I just noticed that I did not update my system after installing from the 2004.1 CD. So there were some interesting changes in net.eth0. I rewrote my extensions based on the current net.eth0.
Created attachment 33745 [details, diff] Patch to also configure using iwpriv This patch should be applied after the main patch and includes configuration of settings done by the iwpriv command.
After my last update, the pcmcia init script no longer terminates, I guess because of some zombie processes. The reason seems to be my dhcpcd in the background simply by "dhcpcd ... &". I changed that to "start-stop-daemon --background --exec dhcpcd -- ...", so far it seems to work. It would be a good idea to somehow integrate pump into this whole net.eth# stuff as an option, but I don't see how.
baselayout-1.11.7-r2 provides everything you have listed here appart from dhcp backgrounding and hwaddr based configuration. I'm not sure if we're going to provide dhcp backgrounding as there are tools for wired connections (ifplugd) which work better. You also have waproamd for wireless connection - which does a similar job to ifplugd As for the hwaddr config, I believe that udev and nameif already provide this functionality.
Well, what do you know? I have dhcp backgrounding in CVS for dhcpcd, udhcpc and dhclient :) Will be in baselayout-1.12.0
OK, I'm trying to implement things from comment#6. So far I could not get udev or ifrename to allow me to first rename a pcmcia device device and then choose a configuration based on this new name. It seems that pcmcia scripts are executed right after the device is detected, before udev or hotplug (and therefore ifrename) has a chance to rename it. Maybe ifrename should be moved from hotplug/net.agent to init.d/net.eth* But somehow I would still prefer one singe config file per network device based on the mac address. This file could contain a new interface name as well as parameters for iwconfig, ifconfig, dhcp and so on. If I move this card to any other computer, I simply copy this file and get all settings as they were before.
Here's a link about renameing network devices in udev http://www.reactivated.net/udevrules.php#example-iface Hotplug uses ifrename before launching the net.xxx script if you check /etc/hotplug/net.agent - however I don't know how pcmcia-cs affects the process as I don't use it myself on my laptop as hotplug by itself is sufficient. ifrename can never happen in net.xxx script because the interface name has already been defined and the script is running .....
I didn't get my pcmcia device working without pcmcia-cs. And I think I wouldn't want do do without cardctl. So I added ifrename to /etc/pcmcia/network, now it kind of works. Sometimes I still get some error messages when shutting down the system, I'm trying to pin them down. I have a NIC in my port replicator. Now I have net.eth1 in my default runlevel and get an error message every time I'm not docked. My script provided functionality for skipping init scripts when the device was not available. Something like this would be nice, without the need to dig into coldplug or something like this.
If eth1 is a wired interface, you can use ifplugd to start and stop the net.eth1 script. This means that you don't have to have net.eth1 in the default runlevel :)
Hi all, I've been thinking about some features I wanted to have in my network scripts for a long time, and this seems to be the right place for discussing it. Essentially, it's two things: 1) The current network scripts always release the DCHP leases with the DHCP server when an interface is brought down, by using "dhcpcd -z". This is not very practical, because it means that the server is free to instantly reuse the IP address for some other client. Then, the next time the interface is brought up, it ends up with some different IP. The way most other clients handle this, is they don't release the address, so the server will be forced to keep the address until it expires. This way, IP addresses are basically static unless there are not enough addresses in the address space. This is also the intended behaviour of dhcpcd, because it will act this way if it receives a SIGTERM. Hence, it would be better if the network scripts would use "kill" instead of "dhcpcd -z". I'm adding a patch to my current net.eth0 script as an example. 2) I am a user of different wireless networks using different configurations of WEP, WPA, DHCP / static IP addresses. It would be really nice if the network scripts could handle that. Ideally, it should work this way: When the interface is brought up, a search for wireless networks is initiated, and the network with the highest priority is associated to. This functionality is basically provided by wpa_supplicant, but I don't know if it will work with all hardware around. As soon as the association is complete (and every time a re-association is done, maybe with some other network in reach), either a static network configuration is loaded or DHCP configuration is done. This requires some triggering method, though, because as far as I know, there is no DHCP client which notices a change in wireless networks or even a down/up cycle of the interface by itself, and then initiates a lease renewal. What do you think about that? If somebody had an idea with what software components this could be done, I would be glad to implement it.
Created attachment 58553 [details, diff] Diff for net.eth0 to change dhcpcd lease behaviour This changes the use of "dhcpcd -z" to using kill, so that the IP address is not released with the server.
Created attachment 59229 [details, diff] patch to make dhcpcd fail-fast when no link detected I hope no one minds me adding this to this bug, it seemed similar enough to stop me from opening up another bug. I roam a bit with my laptop and when I'm at work, I use a static IP, but the failover doesn't work properly because there is a dhcp server on the network that is used for our IP phones. So, my usual solution is to leave the nic unplugged while dhcpcd asks for an IP and let it time out so that the net scripts do the failover. My problem with this: dhcpcd doesn't realize there is no network connection and waits to time out! I tried playing with different timeout values, but only achieved minimal improvements. My final solution was to hack up a patch for dhcpcd so that it will fail quickly if it can't detect a link on the nic. I've only been able to test this on my laptop (sis900 based nic). The patch currently only works for nics supporting MII (ETHTOOL being an alternative), but for nics that don't support it, it fails gracefully and continues on to normal dhcpcd execution path. In other words, this patch will only make dhcpcd fail fast if it can be sure the link is down. Undetermined status is treated the same as link up, and dhcpcd continues it's broadcasting. The alternative would be to make a standalone tool for determining link status and integrating that with the networking scripts.
MAC based config is now in CVS So everything about the origional bug will be available in baselayout-1.12.0-alpha3 Re comment #12 >baselayout-1.11.x now uses -k instead of -z so it works as it should and also has full support for wpa_supplicant =baselayout-1.11.x dhcp_eth0="release" releases the lease - the default is not to =baselayout-1.12.x dhcp_eth0="norelease" keeps the lease - the default is to release it Re comment #13 Please open a new bug and post the patch
Thanks Roy, and sorry, I forgot to check more recent versions myself. I'll try them soon. According to the dhcpcd manpage, using "-k" will send a SIGHUP, though, which won't establish the desired behaviour ... -k and -z only seem to differ regarding the internal lease cache. Sending a SIGTERM seems to be not possible using dhcpcd itself, so you have to use "kill"; that's why I added the patch in #13. Or is the man page mistaken? Oh yes, when you were talking about #13, did you mean #14?
Sorry - yes, I meant comment #14 for the new bug And sorry for not being clear with the DHCP stuff. What I said is true - here's what we do. We release with -k and don't release by sending dhcpcd a SIGTERM - which is what you described :)
I think we can close this now baselayout-1.12.0_pre2 supports (points made by the original report) a) dhcp backgrounding b) we support the fallback_eth0 variable which provided similar support as requested c) wireless support is in d) MAC address based configration of config_001122334455=( "dhcp" ) is in We also have a new rename module which renames interfaces where it can
