[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.
bgmilne at staff.telkomsa.net
Tue Aug 2 17:29:35 CEST 2011
On Monday, 1 August 2011 20:21:21 Maarten Vanraes wrote:
> Op maandag 01 augustus 2011 11:42:26 schreef Thomas Lottmann:
> > Hello,
> > I should have written this mail much sooner, but finally, I am totally,
> > completely and starting to be hatefully fed up of these tools.
> > The Mandriva/Mageia tools that manage the network on computers,
> > especially the wireless networks are completely dysfunctional. While the
> > Network Center does not seem to even communicate with the system tools
> > to know what is happening during the link setup, it does not
> > auto-refresh network lists properly.
> > Since 2010.1 now even mixes up itself in it's own network scripts (the
> > ones stored in wireless.d). This maxes it wrongly detect numerous
> > wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or
> > more nerving, becomes incapable or storing the right authentication
> > information).
My "production" laptop is still currently running Mandriva 2010.x, and I don't
have problems like this. Work networks run WPA2-Enterprise with EAP-PEAP-
MSCHAPv2, home runs WPA2-Personal. In the cases I have seen this, it is
typically a buggy AP (and in some cases, other platforms have also mis-
detected the network details). In some cases, upgrading the AP firmware has
resolved the problem.
But, these are *specific* issues, and need bug reports with detailed
> > A tool that breaks itself is a complete shame!
> > The GUI is also appalling. Despite it's numerous possibilities, it is a
> > mess and 60% of it cannot be used by something else than the system or a
> > network expert.
There are some deficiencies, but in many cases it does at least work. And at
least my network comes up regardless of how I boot, where I booted to, whether
a user is logged in to a desktop or not (which is not the case on e.g.
> > The code itself is undocumented and it extremely difficult to read.
The few times I looked at the code, it was quite readable. Unfortunately, the
pieces I wanted to do something about ended up requiring changes in non-perl
> > These tools are getting really bad and not working properly anyway since
> > a long time now. So either we fix it and improve it (recoding?), either
> > we definitely switch to Network Manager.
Please no. The biggest frustrations I personally have have nothing to do with
net_applet vs NM. My current biggest frustrations are:
1)That wpa_supplicant doesn't return different results on incorrect (WPA2-
Enterprise EAP-PEAP) passwords:
2)That net_applet doesn't prompt for passwords if wpa_supplicant says it needs
a password. I filed a bug for this against Mandriva:
Implementing the required dbus communication would allow a number of other
improvements (e.g. not having to restart wpa_supplicant for configuration
changes, possibly avoid manual parsing/writing of the configuration etc.).
> > I am ready to participate if
> > necessary (despite my lack of competence), but I do not want to see
> > these tools 'as is' on my computer anymore, and no longer want to see
> > these issues that down Mageia's reputation in comparison to other
> > popular projects here such as Arch, Fedora or Ubuntu, who do have proper
> > tools delivered by default.
I disagree with your statement. For example, while Fedora may seem to have
"proper tools", there are many use cases that aren't considered, and a number
of issues are still experienced (at least according to my colleagues reports).
Allowing NM or non-NM, and having both improved would be win-win.
> > This is not the first time I complain about this tool. We should not
> > leave this unchanged. It is far too annoying and pushing to so much loss
> > of time.
> > Yours sincerely,.
> > Thomas.
> personally, alot of problems could likely be attributed to using all those
> several of those apps together.
> imho, the network tools should be redesigned a bit, according to good
> usability, but mostly, either they should all be nicely integrated which
> each other, or we should just have one that does all nicely.
> personally, i find the netapplet the best working and use that exclusively
> to avoid issues.
> but sadly, even netapplet is far from complete.
> as some kind of start, we should have an app that exists in drakconf, but
> also accessible via an applet, but again, perhaps we should have multiple
> applets, with one for each connection.
I don't think this is necessary, the 'Network Center' does an adequate job
(taking into account some limitations in the network scripts).
> eg: a wifi access link, 2 network connections (one of which goes to
> internet), and 3 openvpn tunnels (as an example) it would even be better,
> if bluetooth networking could also be included.
Bluetooth networking *can* be included, but there is an artificial limitation
on only one ppp connection, so you wouldn't be able to have a Bluetooth SPP-
based ppp connection as well as a mobile-broadband-dongle-based connection (or
For bluetooth ppp over SPP, the bluetooth configuration only needs to be done
once ever (if done correctly), the rfcomm connections will be established when
(Or, are you referring to PAN?).
> (this would also allow for
> multiple internet connections at a later time with some advanced routing)
> at the same time, people could tell at a glance if they accidentally use
> more than one internet access method.
You can see this in Network Center.
> about openvpn, some of those are user-related (even though they have
> effects on global routing), especially password related things,
> personally, i think it'd be better if these can only be controlled through
> the applet by the user it's from (with perhaps an option to allow any user
> to control this too)
> again with openvpn, it would be usefull if there was some kind of way to
> know it's not only running, but also if it's essentially active or not,
> and if it's used as a internet gateway.
Well, the general feedback provided to users (also with e.g. ppp connections)
could be improved.
> These are some things which i have noticed over the years of using it and
> listening to end-user problems.
> perhaps the above can be used as a starting point for a usability scheme.
> Thomas, since you feel this strongly, are you willing to spend some time on
More information about the Mageia-dev