This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 855526 - f18a tc6 anaconda cannot connect to a protected wireless network
f18a tc6 anaconda cannot connect to a protected wireless network
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
: 856852 (view as bug list)
Depends On:
Blocks: F18Beta/F18BetaBlocker
  Show dependency treegraph
 
Reported: 2012-09-08 11:38 EDT by Reartes Guillermo
Modified: 2012-11-05 12:46 EST (History)
11 users (show)

See Also:
Fixed In Version: anaconda-18.17-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-05 12:46:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
syslog file, showing the error (106.57 KB, text/plain)
2012-09-08 11:38 EDT, Reartes Guillermo
no flags Details
screenshot (71.32 KB, application/octet-stream)
2012-09-08 11:39 EDT, Reartes Guillermo
no flags Details

  None (edit)
Description Reartes Guillermo 2012-09-08 11:38:45 EDT
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."
Comment 1 Reartes Guillermo 2012-09-08 11:39:36 EDT
Created attachment 611017 [details]
screenshot
Comment 2 Reartes Guillermo 2012-09-18 17:14:51 EDT
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.
Comment 3 Radek Vykydal 2012-09-20 05:29:58 EDT
*** Bug 856852 has been marked as a duplicate of this bug. ***
Comment 4 Mukundan Ragavan 2012-09-22 13:14:56 EDT
I see this too with Intel centrino Ultimate when using F18 alpha.
Comment 5 Piruthiviraj Natarajan 2012-09-22 13:57:18 EDT
I have Intel i3945 and it works good.
Comment 6 Mukundan Ragavan 2012-09-22 19:12:07 EDT
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).
Comment 7 Tom Lane 2012-09-23 03:05:02 EDT
My network uses WPA2 Personal, and it doesn't work with that.  See syslog at bug #856852.
Comment 8 Adam Williamson 2012-09-26 15:39:56 EDT
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.
Comment 9 Adam Williamson 2012-10-04 14:45:20 EDT
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.
Comment 10 Tom Lane 2012-10-04 15:56:06 EDT
(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?
Comment 11 Radek Vykydal 2012-10-04 16:12:57 EDT
I am working on a fix - adding secret agent to anaconda image.
Comment 12 Adam Williamson 2012-10-05 04:31:58 EDT
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.
Comment 13 Radek Vykydal 2012-10-10 09:40:16 EDT
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.
Comment 14 Jacobo Cabaleiro 2012-10-12 12:42:27 EDT
Experienced this with a WPA2-PSK network on F18 beta TC3. Will report back with updated TC.
Comment 15 satellitgo 2012-10-13 11:54:28 EDT
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.
Comment 16 Reartes Guillermo 2012-10-13 17:28:00 EDT
@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.
Comment 17 Tom Lane 2012-10-13 18:01:28 EDT
> Fixed In Version | anaconda-18.17-1

I assume this isn't yet fixed in TC4, then?
Comment 18 satellitgo 2012-10-13 19:50:57 EDT
not for TC4 netinstall  (18.16)
Comment 19 Adam Williamson 2012-10-15 19:01:46 EDT
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.
Comment 20 Fedora Update System 2012-10-16 23:08:18 EDT
anaconda-18.17-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.17-1.fc18
Comment 21 Fedora Update System 2012-10-17 13:29:37 EDT
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).
Comment 22 Fedora Update System 2012-10-17 22:37:18 EDT
anaconda-18.18-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.18-1.fc18
Comment 23 Fedora Update System 2012-10-18 11:29:21 EDT
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).
Comment 24 Fedora Update System 2012-10-19 21:33:00 EDT
anaconda-18.19-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.19-1.fc18
Comment 25 Tom Lane 2012-10-20 18:05:52 EDT
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.
Comment 26 Reartes Guillermo 2012-10-20 18:49:36 EDT
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.
Comment 27 Tom Lane 2012-10-20 19:04:33 EDT
(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.
Comment 28 Reartes Guillermo 2012-10-20 19:09:51 EDT
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.
Comment 29 Tom Lane 2012-10-21 16:14:37 EDT
(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.
Comment 30 Reartes Guillermo 2012-10-21 16:26:14 EDT
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.
Comment 31 Tom Lane 2012-10-21 16:29:55 EDT
(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.
Comment 32 Adam Williamson 2012-10-22 19:45:15 EDT
Tom: did you file a bug with the actual anaconda crash traceback?
Comment 33 Tom Lane 2012-10-23 00:15:11 EDT
(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.
Comment 34 Kamil Páral 2012-10-23 09:21:01 EDT
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.
Comment 35 Adam Williamson 2012-10-23 18:47:14 EDT
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.
Comment 36 Tom Lane 2012-10-23 18:55:29 EDT
(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.
Comment 37 Adam Williamson 2012-10-23 19:42:28 EDT
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.
Comment 38 Adam Williamson 2012-10-24 14:44:57 EDT
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?
Comment 39 Radek Vykydal 2012-10-29 10:02:15 EDT
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.
Comment 40 Radek Vykydal 2012-10-29 12:08:42 EDT
(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.
Comment 41 Adam Williamson 2012-10-29 13:23:01 EDT
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.
Comment 42 Adam Williamson 2012-10-29 13:38:38 EDT
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 .
Comment 43 Mukundan Ragavan 2012-11-03 11:27:22 EDT
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.
Comment 44 Mukundan Ragavan 2012-11-03 11:27:50 EDT
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.
Comment 45 satellitgo 2012-11-03 11:31:20 EDT
TC7 wep configure worked for password: Apple Network xxxxx  (name with spaces)
It connects now in anaconda. fixed
Comment 46 Adam Williamson 2012-11-03 13:01:54 EDT
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?
Comment 47 Mukundan Ragavan 2012-11-03 13:14:37 EDT
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?
Comment 48 Mukundan Ragavan 2012-11-03 13:18:21 EDT
I must also add that anaconda recognizes the wireless adapter just fine.

It shows: Intel Corportation PRO/Wireless 5100 AGN

Which is correct.
Comment 49 Mukundan Ragavan 2012-11-03 14:04:22 EDT
O.K. One more addition - WPA2-Personal works fine. 

I am able to configure the connection and I get a fully functional network connection.
Comment 50 Tom Lane 2012-11-04 11:42:25 EST
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.
Comment 51 Radek Vykydal 2012-11-05 08:16:31 EST
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?
Comment 52 Adam Williamson 2012-11-05 12:46:39 EST
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.

Note You need to log in before you can comment on or make changes to this bug.