Bug 7317 - GNOME Networkmanager by default but disagrees with MCC
Summary: GNOME Networkmanager by default but disagrees with MCC
Status: ASSIGNED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
: High major
Target Milestone: ---
Assignee: Olivier Blin
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
: 8900 8971 (view as bug list)
Depends on:
Blocks: 5187 7557 11844
  Show dependency treegraph
 
Reported: 2012-09-03 18:31 CEST by claire robinson
Modified: 2016-10-10 17:42 CEST (History)
13 users (show)

See Also:
Source RPM: networkmanager or drakx-net
CVE:
Status comment:


Attachments

Description claire robinson 2012-09-03 18:31:56 CEST
Pre Mga3 Alpha1 DVD i586 with default Gnome installation.

Networkmanager is configured by default to start at boot and manage the connection, which it does.

When the connection is viewed and OK'd in MCC however it switches the connection to not being managed by NM and disables the network connection.

If NM is to be used by default in a default Gnome setup then MCC should be set automatically to allow the connection to be managed by NM.

As it is now the two disagree and would leave a novice user with no network connection.
Comment 1 Manuel Hiebel 2012-09-03 19:50:49 CEST
setting to blocker for mageia 3 as it was also so for mga2

but don't know what write in /etc/sysconfig/network-scripts/ifcfg-*
Comment 2 Joe Shmoe 2012-09-12 18:26:11 CEST
I can reproduce being disconnected in this manner in Gnome, LXDE and Xfce, but not that settings are changed.

This is a 3alpha1 i586 net install; originally LXDE. Later updated and installed task-gnome-minimal and task-xfce. I have:

drakconf-12.31-1.mga3
networkmanager-applet-0.9.6.2-2.mga3
networkmanager-0.9.6.0-2.mga3

If "user is allowed to manage connection" or not seems to make no difference.
Comment 3 Joe Shmoe 2012-09-13 00:11:10 CEST
What I said in comment #2 was reliably reproducible in a fair number of tests, but now an additional issue has cropped up: When waking up from suspend, "Enable Networking" in the context menu of the nm applet is unchecked.

And it cannot be checked, as per bug 7467, which I opened because of issues that seem UI related.
Comment 4 Frank Griffin 2012-10-29 13:24:03 CET
Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID.

For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect.  GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there.  

You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface".

Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.
Comment 5 Frank Griffin 2012-10-29 14:14:14 CET
The crux of this problem is that MCC drakconnect provides no way to *edit* an existing configuration, although it looks like this because most of the preselected values in the dialogs will be taken from the existing ifcfg if it exists.  But in reality, drakconnect writes a new ifcfg file.

If you delete the ifcfg files for wireless (including wrieless.d) and let nm-applet bring up the interface, do the ifcfg files get recreated ?  

If not, then it's not a case of drakconnect deliberately disabling NM during redefinition, it's just a case of drakconnect defaulting to not using NM, which is the policy for MGA3.

If so, and if ifcfg has NM_CONTROLLED=YES, the drakconnect needs to be fixed to honor this when setting the dialog defaults.

The release notes should direct GNOME users to *not* use MCC to configure the wireless, but use the NM tolls instead, unless your chip really doesn't work with NM, in which case they should disable NM and use MCC exclusively.  Not sure what this does to GNOME, though.
Comment 6 Manuel Hiebel 2012-11-24 19:02:38 CET
still buggy sometime
Comment 7 claire robinson 2013-01-17 09:43:47 CET
Valid 3beta2
Comment 8 Manuel Hiebel 2013-02-01 01:22:01 CET
*** Bug 8900 has been marked as a duplicate of this bug. ***
Comment 9 Reinout van Schouwen 2013-02-20 11:43:39 CET
Disabling the drakconnect applet when NM is managing the connection is a good idea for another reason: it clutters the Gnome Shell message tray.
Comment 10 Atilla ÖNTAŞ 2013-04-10 01:46:04 CEST
Is it still valid for Mageia3beta4?
Comment 11 claire robinson 2013-04-10 09:42:45 CEST
Has anything changed so that it wouldn't be?
Comment 12 sreejiraj eluvangal 2013-04-13 11:20:34 CEST
I am on beta4 (upgraded from beta3).
When I try to connect using my 3G modem, it shows that it's connected. Everything looks normal. But there is no Internet. A ping on any IP address gives "Network unreachable". This was there initially as well, and continues into beta4. As a result, I have to switch to Suse when I am on my 3G modem.


(In reply to Atilla ÃNTAÅ from comment #10)
> Is it still valid for Mageia3beta4?
Comment 13 Sander Lepik 2013-04-14 17:16:01 CEST
It might be shorewall that is blocking your connection. Try to stop it:

systemctl stop shorewall.service

Does it connect now?
Comment 14 sreejiraj eluvangal 2013-04-15 10:03:18 CEST
Yes, it connects now. Thank You.
Comment 15 Sander Lepik 2013-04-15 10:40:10 CEST
(In reply to sreejiraj eluvangal from comment #14)
> Yes, it connects now. Thank You.

Then you have to add your 3G modem as a local interface. Check with ifconfig how it's named. Probably usb0 but might be something else too. Then open /etc/shorewall/interfaces and add this device following patterns from other local devices like eth0 or wlan0.

After that you should be able to turn shorewall on again.
Comment 16 Malo Deniélou 2013-05-03 15:20:00 CEST
What is the status of this bug with the RC? Thanks.
Comment 17 claire robinson 2013-05-09 12:32:44 CEST
Valid 3RC, see also bug 7676
Comment 18 Olivier Blin 2013-05-11 14:31:14 CEST
(In reply to Frank Griffin from comment #5)
> If not, then it's not a case of drakconnect deliberately disabling NM during
> redefinition, it's just a case of drakconnect defaulting to not using NM,
> which is the policy for MGA3.

AFAIK, we did not make such an explicit policy choice to default to NM, there is has been no real discussion neither a formal choice.

NM just assumes to be the default network manager unless specified otherwise.
Comment 19 Olivier Blin 2013-05-11 14:50:20 CEST
*** Bug 8971 has been marked as a duplicate of this bug. ***
Comment 20 Colin Guthrie 2013-05-11 17:22:05 CEST
Is this a release blocker? Surely it can be fixed after release with updates?
Comment 21 Thierry Vignaud 2013-05-11 18:09:09 CEST
(In reply to Olivier Blin from comment #18)
I think we should investigate in mga4 to default to NM for wifi connections. It seems to handle them better. I've seen several cases where drakconnect didn't succeeds in connecting while NM does.

We could bind NM through perl-Glib-Introspection and maybe introduce a NM connector object in drakconnect
Comment 22 Reinout van Schouwen 2013-05-11 18:15:10 CEST
(In reply to Colin Guthrie from comment #20)
> Is this a release blocker? Surely it can be fixed after release with updates?

Possibly, but how are you going to install updates without network connecction? Also it is confusing to have two distinct network status icons visible at the same time.
Comment 23 Sander Lepik 2013-05-11 21:02:08 CEST
(In reply to Colin Guthrie from comment #20)
> Is this a release blocker? Surely it can be fixed after release with updates?

The current setup will screw Gnome users. NM is enabled by default and soon there will be two wpa_supplicants running at the same time.
Comment 24 Olivier Blin 2013-05-11 22:12:42 CEST
(In reply to Thierry Vignaud from comment #21)
> (In reply to Olivier Blin from comment #18)
> I think we should investigate in mga4 to default to NM for wifi connections.
> It seems to handle them better. I've seen several cases where drakconnect
> didn't succeeds in connecting while NM does.

Maybe because of NM hijacking wireless instances, see bug 6675

But yes, we should think of making it the default for eth and wifi.
netceneter/net_applet could still be helpful for other types of connections.

> We could bind NM through perl-Glib-Introspection and maybe introduce a NM
> connector object in drakconnect

Could be useful.
Comment 25 Olivier Blin 2013-05-11 22:15:11 CEST
(In reply to Colin Guthrie from comment #20)
> Is this a release blocker? Surely it can be fixed after release with updates?

Yes it is, because drakx-net can break a working setup without telling the user "oh hey, I switching from NM to initscripts to handle your interface"

I have a simple patch pending test (almost a one-liner), but bug 9734 is blocking me, NM is unusable on my laptop, it just segfaults :-/
Comment 26 Malo Deniélou 2013-05-12 17:22:14 CEST
Hi Olivier, could you push that patch so that we can test it? Thanks.
Comment 27 claire robinson 2013-05-15 17:22:45 CEST
Valid pre 3 final from classic dvd 32 (1st build)
Comment 28 Atilla ÖNTAŞ 2014-01-16 09:21:21 CET
On my Cauldron install; using NM with wireless connection on MATE Desktop everything is ok. I think this had been fixed somewhere between Mageia 3 final and  current Cauldron. Is this problem still occurs in current Cauldron or Mageia 3 for you?
Comment 29 Rémi Verschelde 2015-02-03 22:04:35 CET
Atilla, can you confirm that it's also fixed in current cauldron (Mageia 5 beta 3)? If so, let's close this one as OLD.
Comment 30 Rémi Verschelde 2015-02-03 22:08:33 CET
Decreasing the priority for now.
Comment 31 Olav Vitters 2015-02-09 11:42:54 CET
I've packaged almost every NetworkManager plugin and tried to ensure this stuff will be installed by default. Enabled conncheck as well as the "tui" (command line interface). Still to do: packaging libteam and enabling support for that.

With above, I'm guessing NetworkManager is pretty advanced now. Also, the purpose changed from just fulfilling the needs of desktops.

For Mageia 5 I guess it is better to stick with MCC. For Mageia 6, I hope enough work is done to make NM possible. Note: low level work I cannot do, I mainly just package.
Comment 32 Marja van Waes 2015-02-09 12:03:36 CET
(In reply to Olav Vitters from comment #31)

> 
> With above, I'm guessing NetworkManager is pretty advanced now. Also, the
> purpose changed from just fulfilling the needs of desktops.

Thanks, Olav :-)

> 
> For Mageia 5 I guess it is better to stick with MCC. For Mageia 6, I hope
> enough work is done to make NM possible. Note: low level work I cannot do, I
> mainly just package.

Well, it certainly looks like high level work to me, this sounds as if any packaging apprentice could do it!

But since you're part of upstream, do you really mean "Note: downstream work I cannot do, I mainly just package what we create upstream"
Comment 33 Colin Guthrie 2015-02-09 13:17:41 CET
(In reply to Marja van Waes from comment #32)
> (In reply to Olav Vitters from comment #31)
> 
> > 
> > With above, I'm guessing NetworkManager is pretty advanced now. Also, the
> > purpose changed from just fulfilling the needs of desktops.
> 
> Thanks, Olav :-)
> 
> > 
> > For Mageia 5 I guess it is better to stick with MCC. For Mageia 6, I hope
> > enough work is done to make NM possible. Note: low level work I cannot do, I
> > mainly just package.
> 
> Well, it certainly looks like high level work to me, this sounds as if any
> packaging apprentice could do it!

Really? I have to disagree here Marja (perhaps you're misunderstanding?). The changes needed to use NM by default are very much quite low level. We need to rip out draknetcenter and net_applet stuff and essentially rewrite and retool them accordingly (or, controversially, just drop them completely!)

If we keep them, they need to be able to act as NM frontends. This is quite low level retooling, although it will mostly involve writing dbus calls to talk to NM. It's probably the point at which we switch the tools over the mana* tools instead that Angelo/Matteo are working on.

And there is an added complication that the networking stuff we have now is used in two contexts - standalone and in the installer. When used in the installer, we do not have dbus to talk to the NM daemon (at least as far as the *installed* system is concerned), so we have to take architectural decisions there too (and appropriate retooling).

Sadly all of this amounts to a sizable proportion of low level work, but it's sorely needed. Not just for GNOME for for the other DEs too. The draknetcenter stuff is really showing it's age - the problems connecting at FOSDEM for most people (when I just connected with NM and forgot about it) really brought that home to me.

The second problem is that as it's relatively low level and involves the installer, there are not many people who are willing, able and have time to do it :s

It's this body of work that Olav is referring to, and to be honest there are only a handful of people capable sadly.
Comment 34 Marja van Waes 2015-02-09 13:56:45 CET
@ colin

Either "low level" just means something very different to me (to me "low level" sounds like "work anybody can do, without special knowledge"), or I should have been more clear. 

I still have to meet the first person who says:
"oh, I looked at MCC and installer and the drakx-net and drakx code, it is all very clear to me: I might break things by forgetting a semicolon or forgetting to define a value, but I'll never break anything because I do not fully understand what all that code does"

So when I said
> Well, it certainly looks like high level work to me, this sounds as if any
> packaging apprentice could do it!

"this" referred to "low level", and _not_ to the work that needs to be done
Comment 35 Colin Guthrie 2015-02-09 14:11:24 CET
(In reply to Marja van Waes from comment #34)
> @ colin
> 
> Either "low level" just means something very different to me (to me "low
> level" sounds like "work anybody can do, without special knowledge"), or I
> should have been more clear. 

Yeah I thought that might have been what you meant :)

In this context, high-level and low-level refers to programming languages and operating systemd design paradigms. http://en.wikipedia.org/wiki/High-level_programming_language (and the link to low level).

High level is stuff near the top which works with nicely defined APIs and which are relatively easy to work with, but low level is stuff that requires deeper knowledge of how things work and how everything fits together!

> I still have to meet the first person who says:
> "oh, I looked at MCC and installer and the drakx-net and drakx code, it is
> all very clear to me.

Haha :) Indeed :p

> So when I said
> > Well, it certainly looks like high level work to me, this sounds as if any
> > packaging apprentice could do it!
> 
> "this" referred to "low level", and _not_ to the work that needs to be done

OK, I can see the confusion. Anyway, just so you know for future reference, the low level bits here are the hard bits, and the high level stuff is relatively easy :)
Comment 36 Marja van Waes 2015-02-09 14:23:03 CET
(In reply to Colin Guthrie from comment #35)

> 
> OK, I can see the confusion. Anyway, just so you know for future reference,
> the low level bits here are the hard bits, and the high level stuff is
> relatively easy :)

Thx for the clear explanation and the wikipedia link, Colin :-)
Comment 37 Samuel Verschelde 2016-10-10 17:42:37 CEST
This bug report has seen no activity over the last 609 days. Is it still valid?

Note You need to log in before you can comment on or make changes to this bug.