Created attachment 611016 [details] syslog file, showing the error Description of problem: There is no way to configure the network, so there is not possible to associate with a protected wireless network. You can select the SSID but nothing more. Version-Release number of selected component (if applicable): fedora 18 alpha tc6 How reproducible: always. Steps to Reproduce: 1. boot 2. try to connect to a wireless network with password Actual results: not possible Expected results: possible Additional info: attached screen-shot and syslog file: "WARNING NetworkManager: <warn> No agents were available for this request."
Created attachment 611017 [details] screenshot
The same with F18a RC3 (Anaconda 18.6.8). I propose it as a blocker for beta, to be able to test installing from network using beta.
*** Bug 856852 has been marked as a duplicate of this bug. ***
I see this too with Intel centrino Ultimate when using F18 alpha.
I have Intel i3945 and it works good.
I guess I should have been more specific. The problem I am seeing at this point is with WPA2-Enterprise. I will try at my home network and add info (wpa-personal).
My network uses WPA2 Personal, and it doesn't work with that. See syslog at bug #856852.
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . Our current understanding of this bug is that any form of wireless connection which requires authentication will not work. On that basis, this was accepted as a blocker per criterion "The installer must be able to use at least one of the HTTP or FTP remote package source options" , in the case of using an authenticated wireless connection. We agreed such connections are important enough these days that they ought to work by Beta.
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . It looks like this needs to be re-tested with Beta to verify it's still a problem. Can someone please re-test with Beta TC2 - http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC2/ - and confirm whether this is still an issue? thanks.
(In reply to comment #9) > Discussed at 2012-10-04 blocker review meeting: > http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker- > review-2.1.2012-10-04-16.00.log.txt . It looks like this needs to be > re-tested with Beta to verify it's still a problem. Can someone please > re-test with Beta TC2 - > http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC2/ - and confirm whether > this is still an issue? thanks. Beta-TC2 acts exactly the same as the alphas did, ie, no response to Configure button, VT1 shows the async_got_type bleat repeatedly. Is it that hard for people to try this against a router with WPA2 password protection?
I am working on a fix - adding secret agent to anaconda image.
Tom: trying it is not hard at all, no, you've just proved that. It just didn't happen to have been done yet. We have a lot of tests to run against TCs.
Fix sent for review to anaconda-patches. You can check it with this updades image (for Beta-TC2): http://rvykydal.fedorapeople.org/updates.wificombo.img With this fix, wireless secrets can be set in nm-c-e with [Configure] button. I am planning to use secret agent for wireless secrets (either nm-applet or our own). Currently NM requires running session for secret agent which is very hard to achieve in Anaconda. Dan Williams is working on support for private dbus socket where session will not be required for the agent.
Experienced this with a WPA2-PSK network on F18 beta TC3. Will report back with updated TC.
smoke 8 an 9 behave the same no response to [configure] button on wireless. HD install with wep wireless AP. It sees it but will not configure.
@Radek Vykydal I tested F18b TC2 with the updates image from comment #13 and i was able to authenticate correctly to my wireless network. The 'configure' button worked correctly. There was a slight UI sluggishness but it was very short. (This was tested in a KVM GUEST with USB WLAN pass-through). I even disabled the wired network and used the wireless connection to switch to nearest mirror. And i was able to switch groups KDE / LXDE with nearest mirror installation source over wlan0. (Tested with WPA Personal / AES) It looks good to me.
> Fixed In Version | anaconda-18.17-1 I assume this isn't yet fixed in TC4, then?
not for TC4 netinstall (18.16)
Tom: indeed, TC4 has 18.16. Usually a 'fixed' anaconda bug will be in POST if a fix has been posted to the anaconda-patches list but not yet committed, MODIFIED if it's been committed but not yet incorporated into a build, and ON_QA when it's actually made it into a build.
anaconda-18.17-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.17-1.fc18
Package anaconda-18.17-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.17-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16295/anaconda-18.17-1.fc18 then log in and leave karma (feedback).
anaconda-18.18-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.18-1.fc18
Package anaconda-18.18-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.18-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16402/anaconda-18.18-1.fc18 then log in and leave karma (feedback).
anaconda-18.19-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.19-1.fc18
Beta-TC6 works, kinda, sorta, for small values of "works". I get to the network configuration screen, select the wireless card, select my network, hit "Configure" ... and the configuration dialog appears. So that's a huge step forward. But after I enter my configuration and click Save, nothing happens --- the state of the card is still shown as Disconnected. Undaunted, I press Continue, and come to the "hub" page where likewise the network state is "disconnected". I click on the network link and go back to that page, where I have to reselect my network --- and then it shows Connecting, and a bit later Connected. (And at this point the machine starts answering pings, so yes it is connected.) Then I hit Done to go back to the hub page, and anaconda immediately crashes ("An unknown error has occurred"). So this is not exactly working yet. [ further experimentation ... ] If I reselect the correct network after clicking Save, I can get it to connect before leaving the network setup page. However, anaconda still crashes immediately on pressing Continue. In this path it doesn't even manage to show the hub page before crashing.
With F18b TC6 and with this setup: KVM GUEST with WLAN USB Pass-through (WPA Personal / AES) This worked for me: 1. enter network, disable the wired network first. 2. choose the network name 3. press configure and set the password in wireless security and press save while one might expect the connection to be established immediately, it is not, as previous comment explained. 4. choose the network name again, then it will connect with the previously configured password. (as previous comment also explained). 5. return to the main hub. no crash. I even tested switching INSTALLATION SOURCE to CLOSEST MIRROR and it worked. Additional note: * Returning to the main hub while wlan is 'connecting' worked. * Returning to the main hub after the first 'save' action also worked.
(In reply to comment #26) > This worked for me: > 1. enter network, disable the wired network first. Hm, I do not see any disable button for the wired network (my ethernet card is unplugged anyway). I tried setting method = disabled in the Configure IPv4 dialog for the ethernet card, but no joy - anaconda still crashes.
For each network device, there is a enable / disable switch. It is not a button, it is (in my perception) a ON-OFF Light-Switch placed horizontally. It seems to be like some form of skeuomorphism. It says 'ON' in blue. If you click it, it will say 'OFF' in gray.
(In reply to comment #28) > For each network device, there is a enable / disable switch. > > It is not a button, it is (in my perception) a ON-OFF Light-Switch placed > horizontally. It seems to be like some form of skeuomorphism. > > It says 'ON' in blue. If you click it, it will say 'OFF' in gray. I see this button for my wireless card, all right, but it is *not* present when my ethernet card is selected. [ experiments some more ... ] I found that if I navigate to the hub screen and back to the network setup screen, the disable switch is visible for the ethernet card (as long as I don't select the wireless card; if I do, after reselecting the ethernet card it vanishes again). But it's already showing as OFF. I tried manually flipping it ON then OFF at that point, but no help --- anaconda still crashes instantly on return to the hub page. This seems to happen on second return to the hub page whether I've configured the wireless card or not. [ experiments some more ... ] I went and found an ethernet cable and plugged the laptop into my router physically, and then the network panel works a *little* more sanely: at least the disable switch for the wired-ethernet card shows up reliably, and anaconda doesn't crash on return to the hub screen. Things still don't actually work though; in particular the "installation source" page doesn't offer me any working options. I notice also that when the cable is plugged in, it takes me from the keyboard config screen directly to the hub screen, as if it thinks that no networking configuration is required. (Wrong. I don't run a DHCP server on my home network, so the ethernet card isn't actually useful either without manual configuration.) Oh, and if I disable the ethernet card, configure the wireless card, and then go back to the home screen ... anaconda still crashes. Basically, TC6 does not work at all in my environment. I suspect it only works in an environment where the wired-ethernet connection works without any manual configuration, because it looks like the installation-source page fails unless it can be correctly populated *before* control arrives at the hub screen.
I suggest to open another bug-report for the missing on-off switch and leaving this one for tracking wlan functionality only. If possible try to get snapshots of the missing button.
(In reply to comment #29) > Basically, TC6 does not work at all in my environment. I suspect it only > works in an environment where the wired-ethernet connection works without > any manual configuration, because it looks like the installation-source page > fails unless it can be correctly populated *before* control arrives at the > hub screen. More testing seems to confirm that: I spun up a DHCP server on another machine, and then I was able to get TC6 to behave a little bit sanely, in that installation source seemed to be acting all right. But, again, only as long as it was running through the wired-ethernet connection. Disable that, configure the wireless card instead (even with use of DHCP rather than manual addressing config), and anaconda still crashes. This clearly hasn't been tested in anything less than friendly, unsecured network environments.
Tom: did you file a bug with the actual anaconda crash traceback?
(In reply to comment #32) > Tom: did you file a bug with the actual anaconda crash traceback? At least one problem is revealed by study of the traceback: bug #869106. But there are sure a bunch of other issues here.
Setting back to ASSIGNED. Radek, please decide whether you want to extend the scope of this bug with some of the feedback, or whether this bug is fixed and people should report separate bug reports about their issues, thanks.
Tom, I mean when you hit a crash/traceback in anaconda, it should offer to let you submit a bug in semi-automated fashion via abrt. I was asking if you had done that.
(In reply to comment #35) > Tom, I mean when you hit a crash/traceback in anaconda, it should offer to > let you submit a bug in semi-automated fashion via abrt. I was asking if you > had done that. I tried, but it complained about broken configuration, and I didn't inquire very hard into why. It seemed likely that the network configuration failure was preventing it from communicating with the abrt server.
oh, yeah...there's an obvious 'chicken and egg' situation there that I missed :) if you have no network connectivity you can grab the raw traceback and all other logs from /tmp at a console (ctrl-alt-f2)...I find the easiest thing to do is plug in a USB stick, mount it, copy them off to that, and then file a bug with them attached.
Discussed at the 2012-10-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.log.txt . anaconda team, can you let us know if you want to keep dealing with wireless networking issues in this bug, or file a new one?
Here are the issues I can see Tom Lane's cases: 1) Spaces in name of active access point result in traceback - bug 869106. I've sent a patch to mailing list. It is quite a serious one in my view, maybe blocking Beta, though the 869106 is proposed only as F18 Blocker. 2) ON/OFF device switch is missing if cable is unplugged. This is by design, after plugging the cable in the switch should appear. 3) User needs to reselect the access point to get connection activated after setting secrets in [Configure] dialog (nm-c-e). This is probably caused by change of behaviour of NM: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ccfe5fec8d1c1038467e4a56656d8f90bc94d2ed In my tests with TC2 the connection was auto activated after configuring the secrets in nm-c-e (i.e. after update of ifcfg file of the connection), in TC6 it is not. This will be fixed when the changes in NM alowing to use our own secret agent are in. Deserves a separate bug IMO. 4) Failing DHCP configuration considered as connected state. Need to investigate. This probably concerns also the installation source issue which doesn't work in this false "connected" state. Should be a separate bug.
(In reply to comment #39) > 4) Failing DHCP configuration considered as connected state. > > Need to investigate. This probably concerns also the installation source > issue which doesn't work in this false "connected" state. Should be a > separate bug. Working on a fix, hopefully I'll be able to post it tomorrow.
So it sounds like we want all of the other issues split off, and this can be closed. I'll file bugs for the currently unfiled issues and link them here.
DHCP issue filed as https://bugzilla.redhat.com/show_bug.cgi?id=871129 . Having to re-select the AP after entering password filed as https://bugzilla.redhat.com/show_bug.cgi?id=871132 .
F18 TC7 with anaconda 18.24 is still unable to connect to WPA2-Enterprise. It is not crashing now, but still cannot connect. Clicking on "configure" button either in pre-hub network setup or network setup from hub does not so anything. No configuration options - no connection.
F18 TC7 with anaconda 18.24 is still unable to connect to WPA2-Enterprise. It is not crashing now, but still cannot connect. Clicking on "configure" button either in pre-hub network setup or network setup from hub does not so anything. No configuration options - no connection. reopening the bug.
TC7 wep configure worked for password: Apple Network xxxxx (name with spaces) It connects now in anaconda. fixed
nonamedotc: please be more specific, we've been testing this quite a lot and that doesn't match the experience. Are you booting a live image or non-live?
My apologies for the comment with no information. TC7 net install image written to USB using dd. The connection I am attempting to connect is WPA2-enterprise. There is nothing wrong with the network. I am using the same network to post this comment. I am trying to install on a Thinkpad T500 on which the installer by itself works fine (so far) if I connect to ethernet connection. The wireless adapter manufacturer is Intel and I am able to connect to wireless without problems from a installed system. Is there some log file that would be helpful?
I must also add that anaconda recognizes the wireless adapter just fine. It shows: Intel Corportation PRO/Wireless 5100 AGN Which is correct.
O.K. One more addition - WPA2-Personal works fine. I am able to configure the connection and I get a fully functional network connection.
I can confirm that TC7 is able to connect to my WPA2-Personal wireless network. There still seems to be a lot of wonkiness around the installation source/software selection steps, but it doesn't look like that's down to the network code. Can't test the WPA2-Enterprise case.
I am afraid for WPA2-Enterprise we can't use our current way of: 1) add_and_activate_connection with no secrets provided 2) connection is created and fails silently 3) enter secrets for the connection in nm-c-e via [Configure] button 4) reactivate the connection (done automatically by anaconda) because NM doesn't create connection in step 2): Device activation failed: (32) Failed to determine AP security information (see also https://bugzilla.redhat.com/show_bug.cgi?id=694765) So we really need secret agent (which is planned to be used when NM is patched for private dbus socket) in this case. Am I right, Dan?
OK, it seems we have agreement that this is mainly working. Enterprise is a different case. Please file it separately (though it may well already be filed, so check first.) Let's close this. If you still have networking issues, please ensure they're filed separately.