[Pkg-utopia-maintainers] Bug#754395: Bug#754395: network-manager: breaks networking by no longer reading connections from /e/n/interfaces

Tue Jul 15 15:52:12 UTC 2014

Hey.

On Thu, 2014-07-10 at 18:32 +0200, Michael Biebl wrote: 
> Please attach your /etc/network/interfaces and a debug log:
attached,... with private data being replaced by ***

> service network-manager stop && NetworkManger --no-daemon --debug
> --log-level=debug
Attached as well...
I guess the 
NetworkManager[9442]: <warn> nm-ifupdown-connection.c.101 - invalid connection read from /etc/network/interfaces: (1) connection.interface-name: 'wlan0-scientia.net' is not a valid interface name
lines show the issue.

> Oh well, managed=true is not really supported and tested. After all,
> having both ifupdown and NM manage the same interface is bound to fail
> in some way anyway.
> 
> I'm inclined to simply rip out that code completely, it's just too
> buggy. I'd suggest you use the keyfile plugin to store your system
> connections.
> 
> Patches to fix managed=true mode are welcome. I'll probably won't spend
> a lot of effort on it.
Well I guess we (and probably many other) won't reach consensus with you
here ever...

The last tech-ctte decision about NM has clearly shown once again, that
NM is *not* the native network configuration system in Debian... nor is
it going to be.
So right now it's merely a wrapper for the actual native tools
(ifupdown, vpnc, strongswan, wpa_supplicant, and so on) and it's only
really use is user-network configuration on desktop machines.

Actually that scenario (end-user/desktop) is the only one where NM works
at least more or less and even there one has so many issues and bugs
upstream is not willing to work on.

- proper integration with the actual native tools (instead of trying to
replace them, while not providing most of their functionality)

- on every upgrade of the NM packages I loose my connections (which
doesn't happen with e.g. ifupdown)

- I happen to see the bug that whenever I loose my wifi connection for
the first time, I have to kill NM and restart it in order to be able to
get *any* new connection

- WPA-EAP connections seem to be much more unstable (many connection
losses) which never happens to me when I start the connection with just
ifupdown/wpa_supplicant  (especially with eduroam, NM seems to have it's
issues)

- security implications (i.e. that normal users can create/alter)
networking connections per default

- with systemd / dbus running one cannot longer stop NM, it will
constantly restart automagically.

I mean all those issues are very real, very annoying,.. many of them
I've reported here or upstream and for most upstream already rejected to
work on,... so long story short: apparently NM isn't mighty enough to
really ever become the native networking configuration tool, and is
merely just a nice framework to tell applications whether you're
connected or not.

Actually most people I know just install it because they have to, since
many GNOMEed programs simply don't work very well without it.

Dropping the ifupdown-plugin and managed-mode, however, seems to be
clearly breaking the standard way of handling networking in Debian...
and I guess this would be a reason why NM should have to be dropped out
of Debian.
This isn't meant offensive (I know you guys have to fight many battles
nowadays with system, and people often attack you)... but I'm quite sure
that many people wouldn't agree if that was the point NM is running
towards... and it would just result in some more tech-ctte rulings
against NM.

One should rather convince upstream to implement full support for the
native backends (including ifupdown).
Well… I've had several tickets for that open, which were all closed as
we-don't-care.

Cheers,
Chris.
-------------- next part --------------
allow-auto	lo
allow-hotplug	eth0

iface lo inet loopback
	dns-search	scientia.net

iface eth0 inet dhcp
iface eth1 inet dhcp

iface usb0 inet dhcp

mapping wlan0
	script	ifscheme-mapping

iface wlan0-scientia.net inet dhcp
	wpa-ssid	scientia.net

	wpa-key-mgmt	WPA-PSK
	wpa-psk		***

iface wlan0-eduroam inet dhcp
	wpa-ssid		eduroam
	#wpa-ssid		802.1X

	wpa-key-mgmt		WPA-EAP
	wpa-eap			TTLS
	wpa-phase2		auth=PAP
	wpa-ca-cert		/usr/share/ca-certificates/mozilla/Deutsche_Telekom_Root_CA_2.crt
	wpa-identity		***
	wpa-password		***
	wpa-anonymous-identity	***

iface wlan0-eduroam_physik.lmu.de inet dhcp
	wpa-ssid		eduroam
	#wpa-ssid		802.1X

	wpa-key-mgmt		WPA-EAP
	wpa-eap			TTLS
	wpa-phase2		auth=PAP
	wpa-ca-cert		/usr/share/ca-certificates/mozilla/Deutsche_Telekom_Root_CA_2.crt
	wpa-identity		***
	wpa-password		***
	wpa-anonymous-identity	***

iface wlan0-mwn inet dhcp
	wpa-ssid	lrz

	wpa-key-mgmt	NONE

	post-up		/usr/sbin/vpnc MWN
	pre-down	/usr/sbin/vpnc-disconnect

iface wlan0-goproHero3 inet dhcp
	wpa-ssid	fraunhofer_scientia_net

	wpa-key-mgmt	WPA-PSK
	wpa-psk		***

iface wlan0-zrenner_kopf inet dhcp
	wpa-ssid	rytxg

	wpa-key-mgmt	WPA-PSK
	wpa-psk		***

iface wlan0-rieger inet dhcp
	wpa-ssid	mein

	wpa-key-mgmt	WPA-PSK
	wpa-psk		***

iface wlan0-said inet dhcp
	wpa-ssid	dlink
	wpa-bssid	00:00:00:00:00:00

	wpa-key-mgmt	NONE

iface wlan0-fabry inet dhcp
	wpa-ssid	maalto

	wpa-key-mgmt	WPA-PSK
	wpa-psk		***
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nm.log
Type: text/x-log
Size: 202643 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20140715/e885442a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20140715/e885442a/attachment-0003.bin>