dhcp3-server is launched before NetworkManager and thus doesn't find interfaces

I'm also running into this.

I've bodged around it by putting the attached script in /etc/network/if-up.d/dhcp3-server . I don't claim it's the best solution, or that it should be included in the package, but it works for my situation (where I have a single interface "eth0" explicitly listed in /etc/default/dhcp3-server), so it might be a useful workaround for others.

Thanks, I'll try this script. Moving the dhcp3-server init-script to S99... doesn't help in my case, btw.
I need the DHCP server to listen on my WLAN card and apparently the delay that results from moving its launch from S40 to S90 isn't sufficient.
Maybe some kind of feedback from NetworkManager via nm-tool would help to solve this, so the dhcp3-server init-script could check on the state of the configured interfaces. Something like "nm-tool --interface wlan0 --state" that would output "connected" it wlan0 is connected.
I guess one also could write a wrapper that parses the output of nm-tool in its current state.

Jacob,

Thanks for that script. It seems to have solved this problem for me as well. I needed the DHCP server to be usable in a headless server where no one is there to log in and use some of the other workarounds people used.

Like others, I wish we did not have to do it this way and still consider this a bug since we should be able to control it as usual for startup ordering. Sadly, that sems not to work though I cannot figure out why.

Larry a.k.a. Dazed_75

Jacob,

Like I said, the script works for me but on review it looks to be flawed. I could not find an email addr for you or we could have reviewed this privately. That might be especially good since I've not done any scripting for many years. If you would be so kind as to review the attached perhaps it will be valuable. I have heavily commented it so please removed most/all of that if you decide to re-submit it.

Jacob,

NM what I said about the assignment operator. Seems that is not true for the Bourne shell in the expression for a test or conditional clause. Also not true for dash (the sh replacement used in some systems), or even in other shells set for POSIX compliance. It is also true that the == operator is not valid in sh or dash.

That said, it looks like the problem is more related to the evolution from fixed configuration to dynamic to accommodate todays more dynamic hardware environment. Perhaps because a DHCP server is [wrongly] thought to be only useful in a non-dynamic server environment, we have this situation where the dhcp3-server configuration methods were abandoned rather than updated.

I don't grok the correct fix yet, but have found the logger command to be very useful in tracking down what is happening.

Larry a.k.a. Dazed_75

I too would like to see a solution to this bug.

I think a good solution might be to extend NetworkManager so that it can be configured to block until it has brought certain interfaces on-line. So, if you were serving DHCP on eth0 and eth2, you could somehow tell NetworkManager (probably just a checkbox in the GUI interface?) that it must bring those interfaces up when it starts, before forking off. Then, as long as you ran NetworkManager before any other networking daemons on boot, you'd be guaranteed the interfaces your networking daemons need.

Thoughts?