2017-01-30 14:29 UTC+01:00, Guus Sliepen <g...@debian.org>: > On Sun, Jan 29, 2017 at 04:46:38PM +0100, Celelibi wrote: >> The interface is therefore marked as configured although it's not. > > It is extremely difficult to say when an interface is configured and > when it is not. Is it when the kernel interface is up? Is it when a > carrier is detected? Is it when the DHCP client is started? When it has > at least one IPv4 address? When you can reach your LAN? Gateway? Another > host on the Internet? > > What if your interface really is up, but then suddenly the DHCP server > stops extending your lease? Or the network connection fails completely? > Or some router on the Internet that is completely out of your control > causes your Internet connection to become useless? Should ifupdown then > consider the interface down again?
Yeah, I get that. But this wasn't the issue I wanted to bring here. And I don't have a definitive answer as well. But since you ask, here is my take on this. To me, an interface is configured (irrespective of ifupdown) when it got all the configuration it needs to get. Therefore, with ifupdown, it's either when it has the manual IP / netmask / gataway / etc, or when the dhclient succeeded in getting a configuration from the server. Additionally, with ifupdown, there's also a matter of allowing ifdown (without --force) to run the post-down hooks to clean up what the pre-up hooks did, even if the interface couldn't completely get configured. If these two don't match, maybe ifupdown need to register a finer grain state for each interface. Or need to handle the clean up better. One related question I have in the back of my head is: should ifup run the post-down hooks when the pre-up hoos succeeded but the actual network configuration failed? Maybe there's a good reason not to. > > Heuristics that work for you might not work for someone else. Ifupdown > is also not a daemon that is constantly watching what is happening with > the network, it can only do things once when you run ifup. The current > behaviour is a best effort. The reason it goes to the background and to > mark the interface as up is to ensure the computer can continue booting, > as you already mentioned. The DHCP client is still running in the > background, so as soon as you do have a good network connection, you > will get an IP address. > It's because ifupdown isn't a daemon that I prefer it over something like network-manager. :) To me, it's a one-shot configuring tool. ifup should configure completely an interface within a finite amount of time or exit with a failure code. Keeping a daemon running is the background (should it be dhclient) is exactly what I try to avoid. What if after a few hours dhclient finally get to configure eth0? It will also mess up the routes that have been set up by the dhclient running on wlan0, thus breaking everything. >> The main inconvenience for me is that it floods the logs with useless >> messages. > > Can you give me an example of those messages in your logs? This is maybe > something that can be improved. It's dhclient's logs, waking every few minutes and trying to get an IP address for 60 seconds. I don't have the logs right now, but I'm sure you know what I'm talking about. I don't think ifupdown can do anything about those logs, and I don't think this would be the right solution either. At least for me. > >> It is however desirable on laptops to have dhclient exit when the >> network is not connected. So that the interface would not be marked as >> configured by ifupdown and even down at the system level. > > This has been asked by others as well, but this is also not as easy as > it seems. With most network cards nowadays, whether wireless or wired, > the only way to find out if you can connect to the network is by > actually bringing the network interface up and to wait for a while, and > for wireless networks you need to try to associate with an access point > before you know if you can connect to it. You cannot trust the link > status of an interface that is down. I have no problem with bringing the kernel interface up to try to get a reply from a DHCP server. However, I think that this "up but unconfigured" state should be transient and either lead quickly to to fully configured state or a down state. After all, ifupdown isn't a daemon. IMO, the right workflow would be: 1) Run the pre-up hooks. 2) Run dhclient -1. 3.a) If dhclient succeed, mark the interface as configured for ifupdown and run the post-up hooks. 3.b) If dhclient failed, bring the kernel interface down (and maybe run the post-down hooks). > >> Maybe it would be nice to add an ifupdown config file, like >> /etc/ifupdown.conf in which we could add some options? In this file we >> would either add a "tryonce" option, or command line options for >> specific DHCP clients. >> Just a suggestion. > > I'll have a look if that is easy to do, but in any case that would be > something for after the release of Debian stretch. That's definitely not a pressing issue for me. Just an inconvenience. Best regards, Celelibi
