[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

[Maarten Vanraes]

Op dinsdag 02 augustus 2011 17:29:35 schreef Buchan Milne:
> 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
> information.
> 
> > > 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. Fedora).
> 
> > > 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 parts.
> 
> > > 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:
> http://hostap.epitest.fi/bugz/show_bug.cgi?id=399
> 
> 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:
> https://qa.mandriva.com/show_bug.cgi?id=51705
> 
> 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 ADSL).

why would there be only 1 possible ppp connection? that sounds odd.

> 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 necessary.
> 
> (Or, are you referring to PAN?).

i think i was, yes, but i'm not too clear on how this sort of thing works

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

yes, but i'm not really a fan of network center, and the whole point of the 
net_applet is that you can always see it, in your systray area. which is where 
i'd like to have all current networking connections separately, so you can 
have 3 openvpn connection and 3 icons, it can more easily show you which are 
working and which aren't.

each of those icons should be 4 state, off-state (but present), on-state, fail-
state and gateway-state (this connection is use as one of the default routes.)

(incidentally, i'd also like for most connections to set up default route and 
having some small advanced routing that would at least enforce symmetrical 
routing.

eg: each such icon could have as right click menu:
 - enable/disable
 - reconnect (?)
 - use for internet (default route)
 - delete
-------------------
 - add new connection (wizard with several types: vpn, virtual interfaces, 
bonds, bridges, etc... )
 - firewall ----> (firewall options)
---------------
 - network center
 - help
 - exit

ie: no more "followed interface, and the like options, because they only 
confuse people.

in drakconf there should then be a network center which is the same thing if 
you click on the net_applet on network center.

the network center should also be an extension of net_applet, the same icons 
should be shown, but bigger with the same states and same right click menu,.


iow: i would like them all to be nicely integrated with eachother.


> > 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 this?
> 
> Regards,
> Buchan