> I disagree to an extent, the problem doesn't sound specific to > wpa_supplicant's shell glue at all,
If wpasupplicant tells ifupdown that it's done configuring the interface, and that everything went fine, but it that's not actually the case... That's wrong. No matter how you look at it. > but rather, the inflexibility of the statically maintained ifupdown > software on an ever evolving Debian/Ubuntu software ecosystem. What exactly do you mean by "statically maintained"? > A "cheap" fix could be included in an individual ifupdown hook script, > but it strikes me that the central network dispatcher/configurator > framework should be striving to handle situations such as that > described, as future hooks may also fall prey to this pitfall. "situations such as that described"? You mean a particular application having specific needs? It's not ifupdown's responsibility to know about all these things. If wpasupplicant doesn't know when it can expect to be succesful, how on earth should ifupdown know? Leaving this decision to each of the modular network configuration things is the right thing to do. I don't see any reason at all why you'd want to put something like that into ifupdown. -- wpasupplicant doesn't start when the network start https://bugs.launchpad.net/bugs/44194 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
