Bug#509006: network-manager: Loses wired connection upon upgrade (from 0.6.6-2+b1 to 0.7.0~svn4191-1)
Cyril Brulebois
Version: 0.7.0~svn4191-1
Severity: important
(It may deserve a higher severity, but oh well, that's experimental, and
“dhclient eth0 did the trick.)
Hello,
after upgrading from 0.6.6-2+b1 to 0.7.0~svn4191-1, I lost wired
connection. Upon “network-manager restart” I get:
,--[ daemon.log ]--
| ** Message: NM disappeared
| Dec 17 11:59:44 talisker NetworkManager: <WARN> nm_signal_handler(): Caught signal 15, shutting down normally.
| Dec 17 11:59:45 talisker NetworkManager: <info> starting...
| ** Message: NM appeared
| Dec 17 11:59:45 talisker NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/dell_wlan_switch
| Dec 17 11:59:45 talisker NetworkManager: <info> eth0: driver is 'tg3'.
| Dec 17 11:59:45 talisker NetworkManager: <info> Found new Ethernet device 'eth0'.
| Dec 17 11:59:45 talisker NetworkManager: <info> (eth0): exported as /org/freedesktop/Hal/devices/net_00_21_70_b3_3d_e8
| Dec 17 11:59:45 talisker NetworkManager: <info> (eth0): now unmanaged
`--
nm-tool reports:
,--
| cyril@talisker:~$ nm-tool
|
| NetworkManager Tool
|
| State: disconnected
|
| - Device: eth0 ----------------------------------------------------------------
| Type: Wired
| Driver: tg3
| State: unmanaged
| Default: no
| HW Address: 00:00:00:00:00:00
|
| Capabilities:
| Supported: yes
| Carrier Detect: yes
| Speed: 1000 Mb/s
|
| Wired Settings
`--
And nm-applet reports the wired network is unsupported.
Let me know if I can send you more input, or test other versions (source
packages are OK).
Cheers,
--
Cyril Brulebois.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28-rc7-kibi-00200-gf7a8db8 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages network-manager depends on:
ii adduser 3.110 add and remove users and groups
ii dbus 1.2.1-4 simple interprocess messaging syst
ii hal 0.5.11-6 Hardware Abstraction Layer
ii ifupdown 0.6.8+nmu1 high level tools to configure netw
ii libc6 2.7-16 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.1-4 simple interprocess messaging syst
ii libdbus-glib-1-2 0.76-1 simple interprocess messaging syst
ii libgcrypt11 1.4.1-2 LGPL Crypto library - runtime libr
ii libglib2.0-0 2.16.6-1 The GLib library of C routines
ii libgnutls26 2.4.2-4 the GNU TLS library - runtime libr
ii libgpg-error0 1.4-2 library for common error values an
ii libhal1 0.5.11-6 Hardware Abstraction Layer - share
ii libnl1 1.1-3 library for dealing with netlink s
ii libnm-glib0 0.7.0~svn4191-1 network management framework (GLib
ii libnm-util0 0.7.0~svn4191-1 network management framework (shar
ii libpolkit-dbus2 0.9-1 library for accessing PolicyKit vi
ii libpolkit2 0.9-1 library for accessing PolicyKit
ii libtasn1-3 1.5-1 Manage ASN.1 structures (runtime)
ii libuuid1 1.41.3-1 universally unique id library
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii wpasupplicant 0.6.4-3 Client support for WPA and WPA2 (I
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages network-manager recommends:
ii network-manager-gnome 0.7.0~svn953-1 network management framework (GNOM
ii policykit 0.9-1 framework for managing administrat
Versions of packages network-manager suggests:
ii avahi-autoipd 0.6.23-3 Avahi IPv4LL network address confi
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
It says unmanaged, not unsupported.
Unmanaged means, that you have configured that device in /etc/network/interfaces
The 0.7.0-1 package (currently in NEW), will have a README.Debian, which
describes what that means. My private repo [1] contains what will be in
experimental (soo)
>
> Let me know if I can send you more input, or test other versions (source
> packages are OK).
Could you describe in more detail, what your actual problem is?
What does your /e/n/i look like? Do you have other network interfaces (other
than eth0) which are managed by NM?
Michael
[1] http://debs.michaelbiebl.de/network-manager/
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Cyril Brulebois
> > And nm-applet reports the wired network is unsupported.
> ^^^^^^^^^^^
> It says unmanaged, not unsupported.
> Unmanaged means, that you have configured that device in /etc/network/interfaces
OK, got caught by l10n: the French translation is ambiguous, since
“n'est pas gérée” can be understood both ways; and it's usual to do
“supported” → “géré” rather than “supporté” (which is considered as an
anglicism).
> > Let me know if I can send you more input, or test other versions (source
> > packages are OK).
>
> Could you describe in more detail, what your actual problem is?
It's actually more subtle than I thought: nm reports that there's no
connection, so liferea, epiphany, etc. went in disconnected mode; since
I called “dhclient eth0”, I've got a connection back. To check nm does
its job, I down'd the interface (“ifconfig eth0 down”), and restarted
nm, but nm doesn't look like wanting to re-up it.
I could try after a fresh restart if you like, but it really sounds like
nm isn't considering the interface.
> What does your /e/n/i look like? Do you have other network interfaces
> (other than eth0) which are managed by NM?
,--
| auto lo
| iface lo inet loopback
| auto eth0
| iface eth0 inet dhcp
`--
I also tried to remove all eth0 references, and restart nm, but it's not
going any better (nm-tool reports exactly the same as in my initial
report).
FWIW (since network drivers are concerned), I'm using a mailine kernel
(2.6.28-rc7-kibi-00200-gf7a8db8).
Cheers,
--
Cyril Brulebois
Michael Biebl
thanks
Cyril Brulebois wrote:
> Michael Biebl <bi...@teco.edu> (17/12/2008):
>>> And nm-applet reports the wired network is unsupported.
>> ^^^^^^^^^^^
>> It says unmanaged, not unsupported.
>> Unmanaged means, that you have configured that device in /etc/network/interfaces
>
> OK, got caught by l10n: the French translation is ambiguous, since
> “n'est pas gérée” can be understood both ways; and it's usual to do
> “supported” → “géré” rather than “supporté” (which is considered as an
> anglicism).
>
>>> Let me know if I can send you more input, or test other versions (source
>>> packages are OK).
>> Could you describe in more detail, what your actual problem is?
>
> It's actually more subtle than I thought: nm reports that there's no
> connection, so liferea, epiphany, etc. went in disconnected mode; since
That's a known issue. For unmanaged devices, NM assumes the state to be offline.
I'm merging this with the existing bug reports.
See e.g. #491826 for more info.
There are some unofficial Ubuntu patches, which make NM always consider the
state to be online, for unmanaged devices. This also has some downsides, but is
probably more sane than to assume a offline state.
(at worst, apps will try to establish a internet connection and fail)
> I called “dhclient eth0”, I've got a connection back. To check nm does
> its job, I down'd the interface (“ifconfig eth0 down”), and restarted
> nm, but nm doesn't look like wanting to re-up it.
>
> I could try after a fresh restart if you like, but it really sounds like
> nm isn't considering the interface.
>
>> What does your /e/n/i look like? Do you have other network interfaces
>> (other than eth0) which are managed by NM?
>
> ,--
> | auto lo
> | iface lo inet loopback
> | auto eth0
> | iface eth0 inet dhcp
> `--
>
> I also tried to remove all eth0 references, and restart nm, but it's not
> going any better (nm-tool reports exactly the same as in my initial
> report).
You need to restart the system settings service (see the README.Debian file I
referring to in my previous email [1])
sudo killall nm-system-settings
After that, NM should pick up you eth0 interface. An alternative is to configure
eth0 via /e/n/i and set
[ifupdown]
managed=true
Cheers,
Michael
Cyril Brulebois
> That's a known issue. For unmanaged devices, NM assumes the state to
> be offline. I'm merging this with the existing bug reports.
>
> See e.g. #491826 for more info.
Hmm, OK. But that bug has been reported against 0.6.6-2 and previous
versions (unstable's) were working fine for me, so (IMHO) that looks
like a regression from previous versions.
> You need to restart the system settings service (see the README.Debian
> file I referring to in my previous email [1])
> Asudo killall nm-system-settings
>
> After that, NM should pick up you eth0 interface.
FWIW, it didn't. (I checked the daemon restarted, and invoke-rc.d
restarted network-manager as well afterwards.)
> An alternative is to configure
> eth0 via /e/n/i and set
>
> [ifupdown]
> managed=true
That did the trick, thanks.
Cheers,
--
Cyril Brulebois
Michael Biebl
> Michael Biebl <bi...@debian.org> (17/12/2008):
>> That's a known issue. For unmanaged devices, NM assumes the state to
>> be offline. I'm merging this with the existing bug reports.
>>
>> See e.g. #491826 for more info.
>
> Hmm, OK. But that bug has been reported against 0.6.6-2 and previous
> versions (unstable's) were working fine for me, so (IMHO) that looks
> like a regression from previous versions.
It's the same underlying issue.
What has changed though between 0.6 and 0.7 is the way, how NM determines when
to mark a device managed or unmanaged (see the 0.6 README.Debian and the new
README.Debian).
That's why you see this "regression" with 0.7.
(It actually isn't a regression, as you can now controll more easily when to
mark a device managed/unmanaged)
>
>> You need to restart the system settings service (see the README.Debian
>> file I referring to in my previous email [1])
>> Asudo killall nm-system-settings
>>
>> After that, NM should pick up you eth0 interface.
>
> FWIW, it didn't. (I checked the daemon restarted, and invoke-rc.d
> restarted network-manager as well afterwards.)
>
>> An alternative is to configure
>> eth0 via /e/n/i and set
>>
>> [ifupdown]
>> managed=true
>
> That did the trick, thanks.
>
> Cheers,
--
Cyril Brulebois
> It's the same underlying issue.
Alright.
> What has changed though between 0.6 and 0.7 is the way, how NM
> determines when to mark a device managed or unmanaged (see the 0.6
> README.Debian and the new README.Debian).
>
> That's why you see this "regression" with 0.7. (It actually isn't a
> regression, as you can now controll more easily when to mark a device
> managed/unmanaged)
Well, for people who want it to “just work” (and AFAICT that's the aim
of network-manager people), it was previously working, and is no longer
without tweaking a configuration file, hence my calling it a regression
(from an very-end-user point of view).
I agree that having more flexibility isn't a regression, though.
Cheers,
--
Cyril Brulebois
Michael Biebl
> Michael Biebl <bi...@debian.org> (17/12/2008):
>> It's the same underlying issue.
>
> Alright.
>
>> What has changed though between 0.6 and 0.7 is the way, how NM
>> determines when to mark a device managed or unmanaged (see the 0.6
>> README.Debian and the new README.Debian).
>>
>> That's why you see this "regression" with 0.7. (It actually isn't a
>> regression, as you can now controll more easily when to mark a device
>> managed/unmanaged)
>
> Well, for people who want it to “just work” (and AFAICT that's the aim
> of network-manager people), it was previously working, and is no longer
> without tweaking a configuration file, hence my calling it a regression
> (from an very-end-user point of view).
I'm currently considering to switch the default mode to
managed=true
This also has potential pit falls (like ifupdown and NM fighting over who should
manage a device that is listed in /e/n/i). I haven't decided yet.
The long term goal, is to use manage=true as default though.
Michael