I get this problem with both wired and wireless interface. I hit Connect and the connection is eventually made. The net_applet realizes this and is updated accordingly. The Network Center does not, so the Connect button remains the same (it should change to Disconnect).
Hi, thanks for reporting this bug. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Keywords: (none) => TriagedAssignee: bugsquad => mageia
I just wanted to add that if you hit the Connect button, it correctly disconnects the interface, so the only bug is that the button didn't change to say Disconnect.
*** Bug 5948 has been marked as a duplicate of this bug. ***
CC: (none) => unruh
Also in Mageia 2 Not only is the Connect button bad (does not change to disconnect) but the visual feedback on the left edge saying if it is associated or connected (green arrow or checkmarked globe) do not display either. They do if the Network Center is closed and then reopened.
Version: 1 => 2
Thanks for checking this. Changing to Cauldron so that maybe it'll be looked at.
Version: 2 => Cauldron
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
It was already confirmed for Mageia 2 in Commment 4.
Keywords: NEEDINFO => (none)
It is also valid for 2 official release .
Version: Cauldron => 2
CC: (none) => thierry.vignaud
It looks like the problem might be in dbus. While both the net_applet and the networkcenter both place a watch on org.mageia.network, it does not seem to ever return/raise a flag/whatever you call it. I have watched both programs in a terminal and while the org.mageia.monitor.wireless does return and run the relevant subroutine, org.mageia.network does not seem to do so, despite the network going up/down/etc. Of course I have no idea what org.mageia.network on dbus does, or what feeds it so this may be all wet.
Having looked through /usr/share/dbus-1 and /etc/dbus-1 I can find no reference to org.mageia.network. Since I do not understand dbus, I do not know if this means that that service is unavailable, and that is why it is never matched in netcenter. Since netcenter only uses that dbus service and not the org.mageia.monitoring.wireless, it never gets signals that the networking has changed and thus never updates the display. ???
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
I can confirm this is still an issue on Mageia 2. Also, running the applet in IceWM, once connected, when it's supposed to turn the icon into the wifi connection strength indicator, it turns to nothing, and anything that gets drawn on the screen over it stays there.
(In reply to David Walser from comment #12) > I can confirm this is still an issue on Mageia 2. > And in Mageia-3-Beta4! Please, can this failure to change 'Connect' to 'Disconnect' etc. be fixed in time for Mageia-3 offical release?
CC: (none) => maurice
(In reply to Maurice Batey from comment #13) > Please, can this failure to change 'Connect' to 'Disconnect' etc. be fixed > in time for Mageia-3 offical release? That would be nice, but there are several higher priority issues that really do need to be fixed before the release, whereas this one could be fixed later with an update. Also, there's really only one or two developers working on these tools, the installer, and some other things, so they're pretty overloaded.
Unfotunately you (Mageia and Mandriva) have been saying this for the past 4 years and never getting around to it. And it is severe. It basically puts anyone off using Mageia who needs to use wireless. The problem is more severe than just not having a disconnect button show up, and not having the current status of the connection shown on the DrakNetwork page, and always having the system come up with the "Connectin failed" even when it did not. It is also a problem that the whole system does not understand how wpa_supplicant works. You have the ifup-wireless script, which sets all kinds of stuff before handing it of to wpa-supplicant, which completely ignores everything you set. It simply looks through the wpa_supplicant.conf file and grabs the "strongest" essid listed in wpa_supplicant.conf, no matter which one you told it to use. Ie, it completely ignores everything you chose. To set thngs like the essid for wpa_supplicant you HAVE to use wpa_cli. I kludged ifup-eth bu having only copy the relevant entry from wpa_supplicant.conf to another file and using that as the configuration file for wpa_supplicant. If you are always in a place where you only have one essid in wpa_suplicant.conf that you want to use, you will not see this behaviour. However if there are two or three all of which you might want to use, and thus all of which are installed in wpa_supplicant.conf then wpa)supplicant ignores your desires and connects to whatever it wants to. Ie, the whole wireless DrakeNetwork needs to be rewritten, and whoever does so needs to talk with the author of wpa_supplicant so they really understand it and how it works. As has been said time and time again over the past 4 years, wireless is critical to any distribution, and it is a real embarassment and impediment for Mageia to have such a bad wireless connection program.
(In reply to w unruh from comment #15) > Unfotunately you (Mageia and Mandriva) have been saying this for the past 4 > years and never getting around to it. And it is severe. It basically puts > anyone off using Mageia who needs to use wireless. This bug only started with Mageia 2. Mageia 1 did not have this problem. > The problem is more severe than just not having a disconnect button show up, > and not having the current status of the connection shown on the DrakNetwork > page, and always having the system come up with the "Connectin failed" even > when it did not. No, it is actually less severe. If you just close draknetcenter and bring it back up again, it shows the correct status. If you are seeing other issues, it's a different bug. > It is also a problem that the whole system does not understand how > wpa_supplicant works. You have the ifup-wireless script, which sets all > kinds of stuff before handing it of to wpa-supplicant, which completely > ignores everything you set. It simply looks through the wpa_supplicant.conf > file and grabs the "strongest" essid listed in wpa_supplicant.conf, no > matter which one you told it to use. Ie, it completely ignores everything > you chose. To set thngs like the essid for wpa_supplicant you HAVE to use > wpa_cli. Choosing the SSID to connect to through draknetcenter and giving the SSID (when it's hidden) and the WPA key all work fine for me. However, I have seen it every once in a while go a little bonkers and keep changing WPA to Open WEP, forcing me to hand-edit wpa_supplicant.conf to fix it. I can't reliably reproduce it unfortunately. > If you are always in a place where you only have one essid in > wpa_suplicant.conf that you want to use, you will not see this behaviour. > However if there are two or three all of which you might want to use, and > thus all of which are installed in wpa_supplicant.conf then wpa)supplicant > ignores your desires and connects to whatever it wants to. Ie, the whole > wireless DrakeNetwork needs to be rewritten, and whoever does so needs to > talk with the author of wpa_supplicant so they really understand it and how > it works. I have several SSIDs in my wpa_supplicant.conf and it handles this just fine. None of the networks are overlapping and visible at the same time, so if that's what you mean, I'm not sure what happens then. > As has been said time and time again over the past 4 years, wireless is > critical to any distribution, and it is a real embarassment and impediment > for Mageia to have such a bad wireless connection program. Actually one of the reasons we've stuck with Mageia's native program for this over switching to NetworkManager stuff is that it works so well with wireless, and better than just about anything else out there. Several reviews have verified this. Yes bugs are bad and annoying, and it's easy to throw stones, but it's completely unproductive. This is a community distribution. Most of the developers are volunteers and the software is free. You can help by reporting bugs, helping debug things, or even submitted patches to the code. All anyone can do is contribute the best that they can. As I said before, there's really only two developers that work on this code, and they're here because they volunteered to be, but they don't have an infinite amount of time and nobody should expect them to.
Hm, perhaps you are right regarding the "no display of status". (NOte you just need to hit refresh, not restart drakeNetwork.) However the other problem, that of the system not connecting to the essid chosen if there are other options which are available and have been used in the past is a bug that was there in Mandriva2010 or even earlier. I spent a lot of time on this, and filed bug reports, only to have them completely ignored. While you may not have run into them, I certainly have. Yes, you do need overlapping essids (eg at a University). I also got in touch with the wpa_supplicant author who told me a bit about wpa_supplicant(WS). a) The whole attempt in DrakeNetwork to set up the essid etc in ifup-wireless is useless as far as WS is concerned. It completely ignores all that information. It pages through the wpa_supplicant.conf file, trying every essid in there, and then it choses which of the ones that are available on the basis on some heuristic "best one" ( which does not include the fact that the user has actually chosen one.) You have to use wpa_cli to tell WS to use only one of them, if that is what you want (that is what network manager does). I kludged it by extracting from wpa_supplicant.conf ONLY the data on the essid I want, putting it into another file (wireless.d/<essid>.wpa) and using that as the configuration file for WS. That works. The other feature that does not work is if you connect to a wpa essid, and then try to connect to an non wpa (wep or no authentication). It takes a few tries before it works. I have no idea why this is true, but the above procedure or separating out the config file seems to help here. Yes, the bug you saw, that sometimes Draknetwork makes a mistake on the authentication available (thinks wpa is wep). While this might not be too bad, what happens next is bad. It opens the configuration window, and even if the user hits cancel immediately, it rewrites wpa_supplicant.conf anyway, and the only way to fix it is to go into wpa_supplicant.conf and erase the wrong entry. As I said, I have been pointing out these problems for 4 years, and nothing has been done about any of them. I do not understand wpa_supplicant well enough and my perl is non-existant, and my knowledge of dbus is even smaller. However, comparing network_applet and configuration-manager leads me to suspect that there is some problem with what configuration-manager is listening for from dbus, and that is why the Network center is not updating itself. The applet clearly does work, and does update itself, while the network center does not. Buth listen to dbus to get the information, but they listen (if I remember correctly) to different services. I am not just trying to throw stones. I am however frustrated that in 4 years things have simply gotten worse-- new bugs introduced-- without the old ones being fixed. Wireless is a critical service for any laptop. And the constant shuffling off of the fixing of the wireless bugs is very frustrating.
Oh, another bug. I again suggested years ago that wpa_supplicant be compiled with the "Debug to file" option enabled. As far as I know it is still not. This can be extremely helpful in figuring out why a connection does not get made. (eg TTLS v PEAP etc). I agree that the debuggin bunff that wpa_supplicant spews out is overwhelming, but often the critical clue is there. I have recompiled wpa_supplicant with it enabled. But other distribitions (eg Ubuntu) have it enabled by default, rather than have it to be impossible as in Mageia/Mandriva.
You can always try to use NetworkManager which should handle WiFi better. I hope we can switch to it in Mageia 4, but we'll see.
CC: (none) => sander.lepik
(In reply to David Walser from comment #14) > (In reply to Maurice Batey from comment #13) > > Please, can this failure to change 'Connect' to 'Disconnect' etc. be fixed > > in time for Mageia-3 offical release? > > That would be nice, but there are several higher priority issues that really > do need to be fixed before the release, whereas this one could be fixed > later with an update. I suggest it is stronger than 'nice', as newcomers to Mageia-3 will be baffled when - after hitting 'Connect' nothing seems to happen. If it says neither 'Failed' nor changes 'Connect' to 'Disconnect', hey don't know what to think, so they are likely to assume that somehow their 'Connect' request has gone down some dark hole. So what do they do? More than likely they will hit 'Connect' again, not knowing that the function of that key has now changed to 'Disconnect', and so on and so on ... That is a very confidence-damaging situation to be in, and could very well cause them to abandon Mageia. However, as you say, the effort available to fix this is minimal, but the longer it is delayed the further it will recede into the future. So I offer the following quick-fix alternative workarounds to plug the hole temporarily: ------------------------------------------------------------------------- (1) On successful connection, put out a different version of the 'Failed' message. with the text 'Failed' replaced by 'Now Connected'. (Presumably the last thing the user wants to do as soon as connected is disconnect!)They will then exit from Network Centre, and the next time they øpen it the connection status will be correct. OR: (2) As soon as connection is made, automatically Exit from Network Manager, and immediately re-start it, upon which it will show the correct connection status. (If difficult to automatically re-start it, it could be assumed that, instead, the user will do that to see what has happened.)
> (2) As soon as connection is made, automatically Exit from Network Manager, Sorry, c/Network Manager/Network Centre
well you have a icon change in the gui and a popup saying you are connect, so no this bugs is not so critical..
Version: 2 => CauldronWhiteboard: (none) => MGA2TOO
(In reply to Manuel Hiebel from comment #22) > well you have a icon change in the gui and a popup saying you are connect, > so no this bugs is not so critical.. Not so, Manuel! That is the whole problem! There is no feedback whatsoever in the Network Centre window (where 'Connect' was selected). What icon change? The only change anywhere is on the Net_Applet 'tooltip' info, not in the current invocation of Network Centre, where the problem is. A new user will simply keep waiting in Network Centre, expecting - with good reason - to be told there. This bug should not be left mouldering on into the future on a 'some other time' basis, if there is at least a simple quick-fix such as outlined above.
(In reply to Sander Lepik from comment #19) > You can always try to use NetworkManager which should handle WiFi better. I > hope we can switch to it in Mageia 4, but we'll see. I did try NW with Alpha2, and quite liked the interface, but with Beta4 I could not get the change to NW to work. It would be good to have NW as default, rather than needing to make the change. I'm concerned about this bug in NC because of the problem it introduces for new users. For myself, I've come to terms with it, just cursing inwardly...
>2) As soon as connection is made, automatically Exit from Network Manager, The whole problem is that Network Center has no idea that a connection has been made so it cannot do anything. It cannot exit, because it does not know it should exit. It is sitting there waiting for notification of a connection and never gets it, because it is listening on the wrong dbus service( at least that is my hypothesis). The code is all there so that when it gets a message, it will change the icons, change the "connecting button to disconnect" etc. If it knew that the connection was made, it would put up all of the old notices. Ie, the whole fix could be as simple as changing the service it listens to. Certainly the network applet IS listening to the right service while the Network Center is not. At least that was my hypothesis when I looked at this whole thing a year or two ago. I would have to spend time now to reconstruct what it was I looked at then, and unfortunately I also do not have the time. In the change from Mandriva to Mageia the dbus services got renamed (eg from com.mandriva to org.mageia and other renaming) and as part of that I think the wireless services got renamed as well, and the change put into Network Center was the wrong one, while the one in network applet was the right one. I do agree that this is pretty serious. Perhaps sticking in a popup in the Network center to tell people to look at the applet because there is a bug in the Network Center would be a solution. Ie, the "Connecting" popup should contain text saying that it is buggy, and to look at the applet instead. Or to keep hitting Refresh. But it sure would look tacky. Yes, if you know to look at the applet, not the Center, everything is fine. But if, as Maurice says, you keep looking at the Center to see if the connection has been made it is not fine. And the latter is certainly what people (eg, me, Maurice as examples) will do. It is confusing. (You may well ask why I did not try changing the service Network Center listened to as a test. I think the easy answer is twofold-- I was totally ignorant of dbus and was scared to try the change in case I destroyed everything, and since I know that I should look at the applet and could hit the Refresh button I could live with this horrible kludge for myself. I had also wasted a few days of this problem already, and also suspected that Mageia had absolutely no interest in implementing a fix, based on other fixes I had tried to send in to Mandriva and Mageia.(msec replacement of alt-ctrl-del behaviour in /etc/inittab, changing wpa_supplicant to allow it to put out debugging notices, changing ifup-eth so it behaved properly for wireless services, etc.)
Thanks for all of your recent comments, this is a lot more helpful. Hopefully Olivier will see these or someone will look at the applet and draknetcenter code for stuff about dbus services and see that you're correct. It certainly makes sense. (In reply to w unruh from comment #25) > (msec replacement of > alt-ctrl-del behaviour in /etc/inittab, changing wpa_supplicant to allow it > to put out debugging notices, changing ifup-eth so it behaved properly for > wireless services, etc.) You've already mentioned the wpa_supplicant thing here, but I'm assuming there are bugs about the other two issues you just mentioned. Would you mind giving bug numbers?
I too am now trying out the Network Manager, and it is not as bad as last time, I tried it ( primarily because a friend had figured out some of the setup bugs) and has some advantages, but as mentioned, it also has some disadvantages. a) There was a whole bunch of changes I had to make in completely obscure configuration files to get it to work.Eg, nm_applet at present is explicitly forbidden to run on KDE. Why? No idea. Perhaps you are supposed to run some obscure Plasma applet instead. Why? Who knows. b)I find it clunky and confusing. If for some reason it has trouble connecting, it does not say it has some problem connecting, it puts up a popup asking for your password on the wpa connection. That is at least as confusing as the problem with Network Center. When I first set NM up, it was trying to connect using TTLS rather than PEAP. I had no idea what the difference was or that there was a difference, and it presented TTLS as the only default, and I thought it knew better than me what the right thing was. And the only indication of problems was that stupid popup asking for the password was the only indication of a problem. etc. At least Network-applet/and center when it is working does better than that. But this is not the place to be discussing the problems with Network Manager.
Re the other bugs-- They were reported to Mandriva. At present I cannot look them up. But they are a) msec has an explicit line in libmsec.py which reverts any changes made to /etc/inittab in the alt-ctrl-del behaviour to the one Mandriva/mageia put in (ie to have alt-ctrl-del do a reboot rather than a shutdown). This was a disaster for laptops since I used alt-ctrl-del to try to shut it down, only to have it reboot in my case, overheating etc. If the sysadmin changes a behaviour, Mageia should not be second guessing that change, unless it makes the machine unuseable. And having the machine shut down ( halt) rather than rebooting is hardly in that category. b) ifup-eth I have mentioned here. ifup-eth calls ifup-wireless to set all kinds of things about the connection using iwconfig, and then calls wpa_supplicant. All of that setup is useless as wpa_supplicant ignores it if wpa_supplicant is called (for wpa enabled access points) This change is a major rewrite as you would have to use wpa_cli instead IF the connection was a wpa_supplicant type connection. Ie, this one is part and parcel of the discussion here.
(In reply to w unruh from comment #28) > Re the other bugs-- They were reported to Mandriva. At present I cannot look > them up. But they are Please don't hold lack of response to bugs on qa.mandriva.com against us :o) > a) msec has an explicit line in libmsec.py which reverts any changes made to > /etc/inittab in the alt-ctrl-del behaviour to the one Mandriva/mageia put in > (ie to have alt-ctrl-del do a reboot rather than a shutdown). Technically that's a bug, but an extremely minor one. As /etc/inittab isn't used anymore, it should be irrelevant now. > b) ifup-eth I have mentioned here. ifup-eth calls ifup-wireless to set all > kinds of things about the connection using iwconfig, and then calls > wpa_supplicant. > All of that setup is useless as wpa_supplicant ignores it if wpa_supplicant > is called (for wpa enabled access points) > This change is a major rewrite as you would have to use wpa_cli instead IF > the connection was a wpa_supplicant type connection. > Ie, this one is part and parcel of the discussion here. Interesting, OK. Thanks for the details.
>> a) msec has an explicit line in libmsec.py which reverts any changes made to >> /etc/inittab in the alt-ctrl-del behaviour to the one Mandriva/mageia put in >> (ie to have alt-ctrl-del do a reboot rather than a shutdown). >Technically that's a bug, but an extremely minor one. As /etc/inittab isn't >used anymore, it should be irrelevant now. The question is whether that bug has simply been imported into whatever the new procedure is. (I could go into a tirade about the wholesale changes to the startup routines, but this is not the place or time)
So, if I look at connection_manager and network_applet code In network_applet $dbus->{connection}->add_filter(sub { my ($_con, $msg) = @_; if ($msg->get_interface eq 'org.mageia.network' && $msg->get_member eq 'status') { my ($status, $interface) = $msg->get_args_list; print "got connection status event: $status $interface\n"; if ($status eq "add") { checkNetworkForce(); } } }); $dbus->{connection}->add_match("type='signal',interface='org.mageia.network'"); While in connection_manager $dbus->{connection}->add_filter( sub { my ($_con, $msg) = @_; if ($msg->get_interface eq 'org.mageia.network') { my $member = $msg->get_member; my $message = _get_network_event_message($connections, $member, $msg->get_args_list); $on_network_event->($message) if $on_network_event && $message; if ($member eq 'status') { my ($status, $interface) = $msg->get_args_list; print "got connection status event: $status $interface\n"; my $cmanager = find { $_->{connection}->get_interface eq $interface } @$cmanagers or return; #- FIXME: factorize in update_on_status_change() and check why update_networks() calls update_on_status_change() if ($cmanager->{connection}->can('get_networks') && !$cmanager->{connection}->network_scan_is_slow) { $cmanager->update_networks; } else { $cmanager->network::connection_manager::update_on_status_change; } if ($cmanager->{wait_message}) { if ($status eq 'interface_up') { undef $cmanager->{wait_message}; } elsif ($status =~ /_failure$/) { undef $cmanager->{wait_message}; $cmanager->{in}->ask_warn(N("Error"), join("\n", N("Connection failed."), if_($message, $message))); } } } } if ($msg->get_interface eq 'org.mageia.monitoring.wireless' && $msg->get_member eq 'Event') { my ($event, $interface) = $msg->get_args_list; print "got wireless event: $event $interface\n"; } }); $dbus->{connection}->add_match("type='signal',interface='org.mageia.network'"); $dbus->{connection}->add_match("type='signal',interface='org.mageia.monitoring.wireless'") So, if I understand this code at all, when applet gets a message on the 'org.mageia.network' dbus queue with status "add" it forces a refresh. When connection_manger gets a message on that queue, it goes through a huge bunch of stuff, but does not look for status "add", and does not force a refresh. applet works, connection_manager does not. That is the extent of my knowledge. And when it gets a a org.mageia.monitoring.wireless message, it does nothing except print out a message (somewhere). Note that this seems to be the same as on Mandriva 2010, so perhaps what dbus is reporting onto the queue has changed. (wpa_supplicant, mandi,....) So, my suspicion may be all wet, but it is the best I can do to try to help. But as I said, I know nothing about dbus, and virtually nothing about perl.
The relevant code is in start_connection() of /usr/lib/libDrakX/network/connection_manager.pm : if ($cmanager->{wait_message_timeout}) { $cmanager->{wait_message} = $wait; Glib::Timeout->add($cmanager->{wait_message_timeout}, sub { if ($cmanager->{wait_message}) { undef $cmanager->{wait_message}; $cmanager->{in}->ask_warn(N("Error"), N("Connection failed.")) if !$cmanager->{connection}->get_status; } undef; }); } With get_status() doing the check: sub get_status { my ($self) = @_; require network::tools; my ($_is_up, $gw_address) = network::tools::get_interface_status($self->get_interface); $self->{status} = to_bool($gw_address); } So, we likely have to investigate why network::tools::get_interface_status() does not find a gateway address. Yet another change in /proc/net/route ?
On my wlan0 interface, this simple perl code works: #!/usr/bin/perl use lib qw(/usr/lib/libDrakX); use network::tools; use Data::Dumper; print Dumper([ network::tools::get_interface_status("wlan0") ]); Does it work for you?
Status: NEW => ASSIGNED
BTW, it is unrelated to the dbus messages, the only check is calling get_status() after wait_message_timeout. Maybe the timeout is too small and you are connecting a few seconds later?
Yes, that is likely the case. You can see all of the relevant code here: http://svnweb.mageia.org/soft/drakx-net/trunk/lib/network/connection_manager.pm?revision=8040&view=markup start_connection is what it does now, so you can see the timeout and callback. There is some code it looks like for listening on the dbus at the bottom (setup_dbus_handlers), but it doesn't look like it's getting used.
Not sure about this discussion, but the connection is definitely being made before the timeout times out. If you watch the netapplet it reports a valid connection while the "Connecting" message is still displayed and 10 sec later finally the timeout occurs in the Network Center. Ie, the Center is not getting the message that the connection has been made. Note that in the old days in Mandriva, you would get an icon change when there was a linkup to the AP and then another change once dhcp had received the IP address. Neither of these changes in state are being communicated to the connection_manager at present. I would have expected the dbus stuff to work ( and it does seem to for net applet).
(In reply to Olivier Blin from comment #33) > On my wlan0 interface, this simple perl code works: > > #!/usr/bin/perl > use lib qw(/usr/lib/libDrakX); > use network::tools; > use Data::Dumper; > print Dumper([ network::tools::get_interface_status("wlan0") ]); > > Does it work for you? I get %VAR1 = [ '0.0.0.0', '192.168.0.1' ]; while connected with nm_applet (ie Network Manager)
(In reply to w unruh from comment #36) > ... the connection is definitely being made > before the timeout times out. If you watch the netapplet it reports a valid > connection while the "Connecting" message is still displayed and 10 sec > later finally the timeout occurs in the Network Center. Ie, the Center is > not getting the message that the connection has been made. I've just been checking that out and the situation seems not quite like that. If I request Connect, the message "Connecting" comes up, but disappears after about 10 seconds if - as is subsequently found- a connection has been made. (If not, the 'Connection failed" notice appears soon after. Now, if 'Connection failed' is issued after some fixed timeout interval regardless of actual connection status, then the failure notice should still eventually appear even if connection has actually been made. But it does NOT appear after a connection. I waited 5 MINUTES after net_applet showed connection, and the failure notice did NOT appear. So how was NC able to choose whether or not to put out a failure notice, if it doesn't know if a connection has been made?
(In reply to w unruh from comment #25) > >2) As soon as connection is made, automatically Exit from Network > Manager, > > The whole problem is that Network Center has no idea that a connection > has been made so it cannot do anything. It cannot exit, because it does not > know it should exit. And yet - as I've found today - the 'Connection failed' notice does NOT appear if a connection has been made, suggesting that it *does* know of the connection. In that case, perhaps a simple stop-gap fix would be for Network Center to issue a Refresh say, 10 seconds, 15 seconds, and 20 seconds after a Connect has been requested?
Fixed in svn (r8174) This will be in the next drakx-net package, likely before Mageia 3 is out
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
This bug is also for (and was originally filed for) Mageia 2. Can we get the fix backported as well?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to Olivier Blin from comment #40) > Fixed in svn (r8174) > This will be in the next drakx-net package, likely before Mageia 3 is out Could you give a hint as to what the problem was?
Here's the change he made: http://svnweb.mageia.org/soft/drakx-net/trunk/lib/network/connection_manager.pm?r1=8171&r2=8174 Basically, after you click Connect, there's a callback that's set to run after a timeout. If the "Connecting..." dialog is still there, it will close that and give the "Connection failed." dialog. Otherwise it does nothing. He added one thing that also calls _update_on_status_change, which will change the Connect button to say Disconnect if it's connected. I'm actually not sure that change is totally right, since he added the call inside the if statement, so it *looks* like it'll only update the button if the "Connecting..." dialog is still there, but if it has already gone away on its own, it won't. Olivier, WDYT?
Right, there should be a similar fix in the code removing the wait_message "on its own", and not after a timeout. But currently, it seems this dbus event monitoring is broken, I'll try to get a look.
Actually, update_on_status_change() was already called in the callback from setup_dbus_handlers()
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
mdv-network-event was still sending events on com.mandriva, while we are watching org.mageia in drakx-net I will fix this in an initscripts udate. This will make the net_applet/draknetcenter/drakroam detect the connection success/failure as soon as it happens. We had this bug since Mga1 :-/
(In reply to Olivier Blin from comment #46) > success/failure as soon as it happens. > We had this bug since Mga1 :-/ Oh yeah, I did report it for Mageia 1 didn't I? Anyway, reopening again as we'll need to use this bug to QA an update for mga2. (plus no fix is pushed yet in Cauldron either)
unruh, looks like you were right, and nailed it especially in Comment 25. Here's the fix to initscripts: http://svnweb.mageia.org/packages/cauldron/initscripts/current/SOURCES/0103-mdv-network-event-use-mageia.org-instead-of-mandriva.patch?revision=412606&view=markup
Glad the problem was found. I never did understand those lines mdv-network-event in /etc/sysconfig/network-scripts/ifup-eth So the fix is really easy. Just change /com/mandriva and com.mandriva to /org/mageia and org.mageia in /usr/sbin/mdv-network-event. As usual easy if only one knew.
Just to confirm, it works on the one of my machines I have tested it on under Mageia 2. Now the Network Center reports when the association gets made and then when the dhcp connection is made and the button comes up as Disconnect when the connection is made, just as it used to do under Mandriva. And I all I did is change those two lines in mdv-network-event.
(In reply to w unruh from comment #50) > Just to confirm, it works on the one of my machines I have tested it on > under Mageia 2. ..... > And I all I did is change those two lines in mdv-network-event. Well, I've just tried the same changes on Mageia-2 and Mageia-3-Beta4(updated), but - after re-booting - I'm afraid it did not make the slightest difference in either case. Tested by - in Network Center - disconnectng from my router SSID, refreshing, then re-connecting. The icon change and Connect-->Disconnect changes then only appeared after doing a Refresh. Is there some additonal change needed?
(In reply to Maurice Batey from comment #52) > (In reply to w unruh from comment #50) > > Just to confirm, it works on the one of my machines I have tested it on > > under Mageia 2. ..... > > And I all I did is change those two lines in mdv-network-event. > > Well, I've just tried the same changes on Mageia-2 and > Mageia-3-Beta4(updated), i.e.: [root@netbook ~]# cat /usr/sbin/mdv-network-event #!/bin/sh # usage "mdv-network-event <event> <interface> EVENT=$1 INTERFACE=$2 if [ -z "$EVENT" ] || [ -z "$INTERFACE" ] || [ ! -x /usr/bin/dbus-send ]; then exit fi /usr/bin/dbus-send --system --type=signal \ # /com/mandriva/network/status \ # com.mandriva.network.status \ /org/mageia/network/status \ org.mageia.network.status \ string:$EVENT \ string:$INTERFACE \ 2>/dev/null
Try taking out those comment lines. I am not at all sure how bash handles comments in a continuation line. Ie make it /usr/bin/dbus-send --system --type=signal \ /org/mageia/network/status \ org.mageia.network.status \ 2>/dev/null Eg, I just set up the following file #!/bin/bash echo hi\ I am\ #not\ going The output is hiI am#notgoing Ie bash does NOT see the hash mark as occuring at the beginning of the line which it needs to if it is going to treat it as a comment.
Oops That should be usr/bin/dbus-send --system --type=signal \ /org/mageia/network/status \ org.mageia.network.status \ string:$EVENT \ string:$INTERFACE \ 2>/dev/null Must also have the content of those messages included. Also your blank line after those lines you included end the command, meaning you do not have those strings as part of the dbus message. Ie. Do not try to put in comments into a continuation line do not put in extra blank lines.
(In reply to w unruh from comment #55) > Oops That should be > > usr/bin/dbus-send --system --type=signal \ > /org/mageia/network/status \ > org.mageia.network.status \ > string:$EVENT \ > string:$INTERFACE \ > 2>/dev/null Oops indeed! Well spotted. Apologies to all. I had carelessly overlooked the continuation on successive lines. [Makes note not to make changes late in the day.] It now works fine here. I appreciate your patience.
No need to patch your files locally, the fix has been submitted in initscripts a day ago, it is already in the repository.
To comment 25 and comment 48: net_applet and draknetcenter were actually listening to the same (wrong) dbus service. But net_applet is also doing some polling every few seconds using system commands (like ip and route)
Fixed for Cauldron in initscripts-9.41-14.mga3. Update for Mageia 2 still needed.
Keywords: Triaged => (none)Status: RESOLVED => REOPENEDVersion: Cauldron => 2Resolution: FIXED => (none)Whiteboard: MGA2TOO => (none)
(In reply to Maurice Batey from comment #56) > It now works fine here. Just in time to help with connections to hotel WiFi in Italy next week! :-))
(In reply to Maurice Batey from comment #60) > (In reply to Maurice Batey from comment #56) > > It now works fine here. > > Just in time to help with connections to hotel WiFi in Italy next week! > :-)) Both Mageia-2 and Mageia-3-Beta4/RC worked fine on an (unlocked) hotel wifi connection in Italy last week on my Samsung NC110 netbook (Broadcom BCM43225 wifi). Interestingly, after using Mageia-2, when I later booted Mageia-3 it automatically connected to the hotel wifi at *boot* time! That surprised me, as I had believed an automatic boot-time connect was only possible if the system had had a previous connection to the same SSID. Or am I wrong, and it is the wireless hardware that remembers the connection? (Mageia-2 did not connect at boot time initially.)
Looks like we forgot to make an update for Mageia 2. Advisory: ---------------------------------------- mdv-network-event: use mageia.org instead of mandriva.com in dbus events drakx-net is listening for events coming from mageia.org This should fix detection of connection success/failure in net_applet, draknetcenter and drakroam. ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- initscripts-9.34-20.2.mga2 debugmode-9.34-20.2.mga2 from initscripts-9.34-20.2.mga2.src.rpm
CC: (none) => mageiaAssignee: mageia => qa-bugs
Testing complete mga2 32 Confirmed that the connection can be disconnected and show 'Connect' but when connecting doesn't show 'Disconnect' when re-connected. (If that makes sense) After update it does.
Whiteboard: (none) => has_procedure mga2-32-ok
Testing complete mga2 64 Validating. Advisory uploaded. Could sysadmin please push from 2 core/updates_testing to updates Thanks!
Keywords: (none) => validated_updateWhiteboard: has_procedure mga2-32-ok => has_procedure mga2-32-ok mga2-64-okCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGAA-2013-0084.html
Status: REOPENED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED