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-*

Priority: Normal => release_blocker
Source RPM: networkmanager or MCC => networkmanager or drakx-net

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.

CC: (none) => callimera.42

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.

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.

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.

CC: (none) => ftg

still buggy sometime

Whiteboard: 3alpha2 => 3alpha3

Valid 3beta2

Whiteboard: 3alpha3 => 3alpha3 3beta2

*** Bug 8900 has been marked as a duplicate of this bug. ***

CC: (none) => sreejiraj

Disabling the drakconnect applet when NM is managing the connection is a good idea for another reason: it clutters the Gnome Shell message tray.

CC: (none) => reinout

Is it still valid for Mageia3beta4?

CC: (none) => tarakbumba

Has anything changed so that it wouldn't be?

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?

It might be shorewall that is blocking your connection. Try to stop it:

systemctl stop shorewall.service

Does it connect now?

CC: (none) => sander.lepik

Yes, it connects now. Thank You.

(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.

What is the status of this bug with the RC? Thanks.

CC: (none) => pierre-malo.denielou

Valid 3RC, see also bug 7676

Whiteboard: 3alpha3 3beta2 => 3alpha3 3beta2 3RC

(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.

*** Bug 8971 has been marked as a duplicate of this bug. ***

Is this a release blocker? Surely it can be fixed after release with updates?

CC: (none) => mageia

(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

(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.

(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.

(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.

(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 :-/

Status: NEW => ASSIGNED

Hi Olivier, could you push that patch so that we can test it? Thanks.

Valid pre 3 final from classic dvd 32 (1st build)

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?

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.

CC: (none) => remi
Whiteboard: 3alpha3 3beta2 3RC 3final => (none)

Decreasing the priority for now.

Priority: release_blocker => High

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.

(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"

CC: (none) => marja11

(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.

@ 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

(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 :)

(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 :-)

This bug report has seen no activity over the last 609 days. Is it still valid?

No answer, and there have been other activities regarding networkmanager.

Resolution: (none) => OLD
Status: ASSIGNED => RESOLVED
CC: (none) => fri