Red Hat Bugzilla – Bug 818214
kernel is not able to create ad-hoc wifi (hotspot) with WPA encryption
Last modified: 2013-02-13 08:55:16 EST
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.
Kernel version 3.3.2-6
You're probably going to need to provide a lot more info, but I honestly don't even know what to start asking for.
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...
Weeks ago I wrote this letter in Fedora devel mailing list
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.
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?
(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.
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.
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
More complicated changes are needed in NetworkManager to allow to use WEP2 PSK on Ad-Hoc mode .
(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?
(In reply to comment #8)
> Maybe do you mean WPA2?
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:
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.