Bug 910944

+++ This bug was initially created as a clone of Bug #818214 +++

Description of problem:
As evidenced here https://bugzilla.redhat.com/show_bug.cgi?id=787733
The kernel is not able to create ad-hoc networks with WPA encryption.

Additional info:
Kernel version 3.3.2-6

--- Additional comment from Josh Boyer on 2012-05-02 10:24:10 EDT ---

You're probably going to need to provide a lot more info, but I honestly don't even know what to start asking for.

--- Additional comment from John W. Linville on 2012-05-02 11:01:31 EDT ---

You could start by telling us what you actually tried.  WPA over ad-hoc is one of those wierd things that some people want to do but most people don't do...

--- Additional comment from Germano Massullo on 2012-05-02 11:55:19 EDT ---

Weeks ago I wrote this letter in Fedora devel mailing list
http://lists.fedoraproject.org/pipermail/devel/2012-April/166161.html

Let's start from the beginning, because when I wrote that e-mail I was so confused, now instead my ideas are completely clear.

First of all, since KDE ***apparently*** allows you to create adhoc networks with WPA, but, the just created adhoc wifi is unprotected, I thought it was a KDE bug.
I opened a KDE bugreport, but I have been told that it could be a network manager problem, since KDE networkmanager uses Gnome Networkmanager infrastructure.
I tried to create a WPA secured adhoc wifi with Fedora Gnome but you cannot select WPA under security settings menu.
When I was going to open a Gnome bugreport, I found out this report https://bugzilla.redhat.com/show_bug.cgi?id=787733 in which Vladimir Benes tells that it is a kernel problem.
To verify if this happens also on other distros, I runned a Ubuntu 12.04 and even there is not possible to use WPA with adhoc wifi.

The strange thing is that only a few people knows that it is a kernel problem. A lot of people instead thinks it is something with networkmanager. (developers on IRC, etc. the list is so looong)

Laptops used to try:
Thinkpad T41, Thinkpad T60, Thinkpad T61.

--- Additional comment from John W. Linville on 2012-05-02 12:13:06 EDT ---

Well, honestly I don't think there is a general problem -- I have heard reports of people setting-up WPA-protected ad-hoc networks.  Whether or not NetworkManager knows how to do that, I don't know.

Have you tried disabling NetworkManager and then using wpa_supplicant directly to do it?

--- Additional comment from Dan Williams on 2012-05-02 12:49:37 EDT ---

(In reply to comment #4)
> Well, honestly I don't think there is a general problem -- I have heard reports
> of people setting-up WPA-protected ad-hoc networks.  Whether or not
> NetworkManager knows how to do that, I don't know.
> 
> Have you tried disabling NetworkManager and then using wpa_supplicant directly
> to do it?

John; WPA1 Ad-Hoc has been broken in mac80211-based drivers for a really long time (at least 2.6.32) and I don't think upstream has any plans to fix it.  The "real" fix is to get all drivers supporting either WPA2/RSN Ad-Hoc (which may already work for some) or to use real AP mode.

NetworkManager does not currently support real AP mode, but that's what we'd like to transition the hotspot functionality towards.  The Ad-Hoc hotspot mode is sub-optimal for a lot of reasons, but we'll still have to use it for older devices that cannot support AP mode or will never support Ad-Hoc RSN (including the 3945 and 4965 even) but I think the focus should be on good AP-mode support for most drivers.

Latest NetworkManager has actually disabled Ad-Hoc WPA mode due to this issue, because the network created by the supplicant + kernel is actually *open* even when WPA is requested, and no error is reported by the kernel or supplicant here.

In the neat future we'll have real AP mode support using the supplicant's built-in "lightweight" AP mode functionality.  We tried to hit that for F17 but didn't make it.

--- Additional comment from Stanislaw Gruszka on 2012-05-25 07:45:14 EDT ---

Some drivers does not support RSN IBSS, but still this is no reason for creating unprotected IBSS networks, whereas WPA2 protection is requested. Reason of that is lack CONFIG_IBSS_RSN=y in wpa_supplicant .config file. When this option is enabled, wpa_supplicant will fail to do EAP authenticate, if driver does not support RSN IBSS, and will create secured network if driver (and pear stations) have RSN support. Note this is wpa_supplicant-1.0 feature, so this can be enabled only on F-17 currently.

Each driver mark support of RSN by WIPHY_FLAG_IBSS_RSN RSN and that flags is exported to user space by nl80211 NL80211_ATTR_SUPPORT_IBSS_RSN. It could be used by  NetworkManager to enable/disable option to create WPA2 secure Ad-Hoc network.

--- Additional comment from Stanislaw Gruszka on 2012-05-28 10:26:06 EDT ---

wpa_supplicant-1.0 require simple change in SRPM build-config file:

--- build-config.orig   2012-05-28 17:01:54.668059158 +0200
+++ build-config        2012-05-28 17:03:29.440060078 +0200
@@ -30,4 +30,5 @@ CONFIG_DEBUG_FILE=y
 CONFIG_BACKEND=file
 CONFIG_PEERKEY=y
 CONFIG_BGSCAN_SIMPLE=y
+CONFIG_IBSS_RSN=y
 #CONFIG_FIPS=y

More complicated changes are needed in NetworkManager to allow to use WEP2 PSK on Ad-Hoc mode .

--- Additional comment from Germano Massullo on 2012-06-09 04:10:35 EDT ---

(In reply to comment #7)

> More complicated changes are needed in NetworkManager to allow to use WEP2
> PSK on Ad-Hoc mode .

Maybe do you mean WPA2?

--- Additional comment from Stanislaw Gruszka on 2012-06-18 11:00:14 EDT ---

(In reply to comment #8)
> Maybe do you mean WPA2?
Yes.

--- Additional comment from Fedora End Of Life on 2013-01-16 08:13:15 EST ---

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from Fedora End Of Life on 2013-02-13 08:55:16 EST ---

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.