I'm working on an embedded system which has both ethernet and wireless. Using a combination of busybox, ifplugd and dhcpcd for configuring it. If you connect to the Internet via one interface, then via the other, then disconnect the first interface, you will end up with no default route. That is because the default route gets clobbered, and then dropped. I can see in the source code (ifupdown.c) that the parameters to dhcpcd are hard-coded, and don't include the -m parameter. In the case of ethernet, ifplugd runs ifup, which runs dhcpcd. In the case of wireless, a startup script runs ifup, which runs dhcpcd. dhcpcd has a -m flag for setting the metric, and I have confirmed that if I use it manually, I get the desired behavior: there can be two default routes at the same time, one has a higher priority, and if either interface gets de-configured, the other interface's default route remains. So it seems to me the best solution would be a way for ifup to give the -m flag to dhcpcd when it runs it. Maybe it should pay attention to an optional METRIC specification in /etc/network/interfaces: if it is there, then give the -m parameter to dhcpcd. (and other dhcp clients might not support that, or might support it in a different way) I can probably write a patch for that, if you think it is the right approach. Is there a better solution?
My opinion on this matter: http://busybox.net/~vda/no_ifup.txt
Denys, those are good points, however I'm not running ifup -a on startup. ifplugd makes ethernet asynchronous: ethernet is configured when the carrier is detected (cable is plugged in). For wireless though, I do run "ifup wlan0" at startup, but it is not slowing the startup process at all, because it's done in parallel with starting X and the applications etc. I didn't have good luck using ifplugd for wireless, but soon plan to switch to wpa_supplicant rather than iwconfig/ifconfig/ifup, which should make it more asynchronous, and the interface will be constantly managed rather than fire-and-forget. But I would just as soon keep using ifup for ethernet since ifplugd is working nicely. Does anybody have any other architectural objections to the fix I'm proposing, or better ideas how to fix it?
> Denys, those are good points, however I'm not running ifup -a on startup. My other point is that "ifup method" of configuring the network is trying to make C code do what shell scripts do best. You just stumbled over the problem that metric is not passed to dhcpcd via -m option. This can be fixed, yes. How many more similar options and usage cases are there to be fixed? And if we do fix them all (a lot of work), wouldn't ifupdown.c look like a jumbled mess afterwards, with special cases for dozens of different dhcp/ppp/vpn/... clients, multiplied by myriads of network parameters?
You are right that there are potentially many more features someone somewhere could want (although setting up a VPN via "ifup" seems like a bit much to me). Personally, I wasm just wanting this one thing. But basically you are saying ifup is deprecated and should not be used then? Because you believe every embedded system should use scripts instead?
> But basically you are saying ifup is deprecated and should not be used then? No, ifup can still be used. It is not deprecated and it will not be removed. It's just not the best tool for networking configuration, it's too restrictive in what you can do using it.