Network-Manager doesn't initially connect to wired network

can you please attach your /etc/network/interfaces configuration to this bug report?

same problem here with a different driver, from syslog:

NetworkManager: <info> eth0: Device is fully-supported using driver 'skge'.
NetworkManager: <info> nm_device_init(): waiting for device's worker thread to start
NetworkManager: <info> nm_device_init(): device's worker thread started, continuing.
NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'.
NetworkManager: <info> Deactivating device eth0.

after unplugging en replugging the network cable, doing a 'networking restart' or ifdown/ifup, dhcp kicks in properly

NetworkManager: <info> Will activate wired connection 'eth0' because it now has a link.

from /etc/network/interfaces:

# The loopback network interface
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

# The primary network interface
auto eth0
iface eth0 inet dhcp

#iface wlan0 inet dhcp
#auto wlan0

I could fix this problem.

Any interface managed by NetworkManager shouldn't be stated in the /etc/network/interfaces file.

@litmotiv: just remove these lines and network manager should bring up the interface again.

Christian, I cannot agree with your assessment, particularly as GNOME/KDE tools by default write interface with auto + dhcp in the interfaces file and as this was the setting on previous Ubuntu releases that were supposed to work with n-m. So it is clear regression and will cause problems with existing customer base that will upgrade to Gutsy.

On the other hand, it is good to know what is workaround and what could be the route cause of the problem.

thanks christian, remove those lines brought eth0 back online. :-)

i do agree with luka though that this is still a bug, and should be treated as such.

thanks christian, removing those lines brought eth0 back online. :-)

i do agree with luka though that this is still a bug, and should be treated as such.

You are right, Luka, that it will cause problems if GNOME/KDE write such default values.

I've installed my laptop during feisty development, when network-manager wasn't installed by default. So the setting where there all the time and NM didn't have any problem with them.

On Fri, Aug 31, 2007 at 03:20:33PM -0000, Luka Renko wrote:
> Christian, I cannot agree with your assessment, particularly as
> GNOME/KDE tools by default write interface with auto + dhcp in the
> interfaces file and as this was the setting on previous Ubuntu releases
> that were supposed to work with n-m. So it is clear regression and will
> cause problems with existing customer base that will upgrade to Gutsy.
>
> On the other hand, it is good to know what is workaround and what could
> be the route cause of the problem.
>

The route cause is that assuming auto configured interfaces to be
network-manager managed was wrong in the first place.

In a perfect world users could decide to have a network interface
either nm managed or system tools managed. Combining both just gives
you headaches.

(and yes, I admit that in this particular case it might be really a
bug in nm).

For instance consider the case of two auto dhcp entries in interfaces?
What do you expect as a user? you expect that both interfaces are
started upped, but then network-manager can only manage one upped
interface at the same time. So you have a problem :). Either down all
interfaces on nm startup ... or implement some heuristic that will
down all but one interface upon startup.

The other option would be to just not manager configured interfaces at
all ... and fix the kde/gnome tools to allow you to get to that state
without hacking config files.

 - Alexander

I understand that n-m 0.6.x is very limited by design: only manages one connection at the time, no support for static IP config and per-user configuration only. This is why I think it has primary use only for desktop users with simple setup, which more or less means one active connection. I think that is one of the reasons n-m makes sense on desktop only and therefore we should really think what is more likely config in such case.
I would say that your example of two interfaces that are active at boot is probably not very typical configuration - I would say typical desktop has one network interface and laptop have two, but in both cases it is one connection used at the time. So n-m assumption is not that wrong here.

There was some discussion in past to change /etc/network/interfaces config and mark n-m managed interfaces differently (not just dhcp as today) - that way we could differentiate static, dhcp and n-m interfaces. I am not sure if this would be good move, but it is worth considering. Current workaround (remove interface from config file completely to make it work with n-m) already goes in that direction.

I completely understand your pain in maintaining n-m for ubuntu: due to limitations you need to make some shortcuts that will hurt some people. You just need to choose less painful way... ;-)

On Sat, Sep 01, 2007 at 09:28:29PM -0000, Luka Renko wrote:
> I understand that n-m 0.6.x is very limited by design: only manages one connection at the time, no support for static IP config and per-user configuration only. This is why I think it has primary use only for desktop users with simple setup, which more or less means one active connection. I think that is one of the reasons n-m makes sense on desktop only and therefore we should really think what is more likely config in such case.
> I would say that your example of two interfaces that are active at boot is probably not very typical configuration - I would say typical desktop has one network interface and laptop have two, but in both cases it is one connection used at the time. So n-m assumption is not that wrong here.
>
> There was some discussion in past to change /etc/network/interfaces
> config and mark n-m managed interfaces differently (not just dhcp as
> today) - that way we could differentiate static, dhcp and n-m
> interfaces. I am not sure if this would be good move, but it is worth
> considering. Current workaround (remove interface from config file
> completely to make it work with n-m) already goes in that direction.
>
> I completely understand your pain in maintaining n-m for ubuntu: due to
> limitations you need to make some shortcuts that will hurt some people.
> You just need to choose less painful way... ;-)
>

The problem with not managing auto dhcp interfaces is a legacy
thing. How can we transition users that upgrade from feisty (or
before) without breaking their setup.

 - Alexander

fwiw,
blacklisting auto dhcp interfaces from being nm managed (which should fix this bug) is now tracked in bug 139403 ...