Create WPA2 adhoc is Open, not encrypted

Can anyone reproduce this bad behaviour?

I've confirmed this in oneiric (0.9.1.90-0ubuntu6) and precise (0.9.1.90-0ubuntu7).

I glanced at the network-manager-applet code and believe that wpa-none should be supported for ad-hoc networks. I don't see any obvious fixes in the upstream git repo, nor any related upstream bugs. However, I did find this interesting comment in the bug tracker: https://bugzilla.gnome.org/show_bug.cgi?id=654772#c1

Indeed, it's borked. This should be set to High considering it's a security vulnerability; perhaps I'd just go ahead and grey out WPA from the list if that makes a bit more sense and avoids getting people to think their ad-hoc is secure when it's not.

Yes, please do. Either we fix it to properly set up WPA, or we remove WPA from the list, but having it display WPA and actually set up unencrypted is evil.

This isn't quite done yet because making IBSS/RSN (adhoc with wpa2) the default instead of WPA with TKIP (as wpa-none) turns out to be a little more difficult to implement and test than initially expected. So; I'm still working on this.

Even IBSS/RSN seems to either appear as not secured, or fails to be connected to with a quick test using my android phone; we'll explicitly disable WPA when creating ad-hoc networks instead.

This issue is reproducible even without NM, using wpasupplicant directly to create a adhoc network, and is definitely true on iwlwifi and rt2800pci; so it deserves to be looked at at the kernel level.

FWIW, I though I had seen it work properly on ath9k, I'll test again tomorrow to be certain.

In any case, I'm strongly considering blocking the creation of WPA/WPA2 personal networks in NM as a stop-gap measure to avoid people creating insecure ad-hoc networks until that's really fixed in the drivers.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 905748

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

@mathieu-tl can you rely on your quick test connecting with android? Android doesn't support Adhoc per default. With the App Wifi-Analyzer you can see some details.

When I create an AdHoc and select WPA, it's now recognised as WPA. WPA2 would be better, I guess. But before it was open.

Why is it so difficult? It did work in earlier releases (ubuntu 11.04 or before, not shure)

I can reproduce this using a laptop with iwl4965, and a Nexus One.

In Wifi-Analyzer, it is displaying as being "WPA" with a lock icon, but when I go into the wireless settings, it says "Open". I can definitely connect without a password, and can access the Internet through the adhoc network.

I agree that we should disable WPA adhoc networks in network-manager until this is resolved in all kernel drivers.

I installed Ubuntu 11.04 on the same laptop. Creating an adhoc shared network shows "Open" in Wifi-Analyzer, and "Open" in the wireless settings. (Although trying to connect fails to get an IP address).

Philipp; yes, we can rely on that test because Android does support ad-hoc for WPA. WPA2 is another story ;)

We've been able to reproduce it on multiple drivers: iwlwifi, rt2800pci, ath9k and iwl4965. I think we can safely say it's reproducible on most drivers, and thus probably something that needs to be fixed in kernel code outside of drivers' code.

Philipp; you may still want to run 'apport-collect 905748' to add extra information to the bug report which will make things easier to debug; as was suggested by Brad.

Joseph, please define what additional information is needed. As per above, in Brad's automated comment:

"If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.". I think we've satisfied this with comment #15.... Setting back to Confirmed.

AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mtrudel 2885 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xf7f00000 irq 51'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:14f1506e,10280510,00100002 HDA:80862805,80860101,00100000'
   Controls : 14
   Simple ctrls : 6
DistroRelease: Ubuntu 12.04
HibernationDevice: RESUME=UUID=2d9327f8-63ea-4503-a4e5-390ae72852bd
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120209.2)
MachineType: Dell Inc. Vostro V131
Package: network-manager
ProcEnviron:
 LANGUAGE=fr_CA:fr
 TERM=xterm
 PATH=(custom, user)
 LANG=fr_CA.UTF-8
 SHELL=/bin/zsh
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-18-generic root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-18-generic N/A
 linux-backports-modules-3.2.0-18-generic N/A
 linux-firmware 1.71
StagingDrivers: mei
Tags: precise staging
Uname: Linux 3.2.0-18-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sbuild sudo
dmi.bios.date: 10/24/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.name: 0C06WP
dmi.board.vendor: Dell Inc.
dmi.board.version: A03
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: Not Specified
dmi.modalias: dmi:bvnDellInc.:bvrA03:bd10/24/2011:svnDellInc.:pnVostroV131:pvrNotSpecified:rvnDellInc.:rn0C06WP:rvrA03:cvnDellInc.:ct8:cvrNotSpecified:
dmi.product.name: Vostro V131
dmi.product.version: Not Specified
dmi.sys.vendor: Dell Inc.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Running wpasupplicant on the command line with debugging logs enabled shows that it does think it's enabling WPA, even if that doesn't seem to get done at the kernel level.

The above was tested with the simplest form for enabling IBSS/WPA, inspired from the default wpa_supplicant.conf shipped configuration, from the upstream tarballs:

mtrudel@gaea ~/Documents % cat wpa-adhoc.conf
ap_scan=2
network={
        ssid="test adhoc"
        mode=1
        frequency=2412
        proto=WPA
        key_mgmt=WPA-NONE
 pairwise=NONE
 group=TKIP
        psk="passphrase"
}

Attached is a sceenshot of what it looks like on my Android device.

And the same on a different system, with ath9k (with the "host" using iwlwifi):

BSS 4e:75:8f:95:91:12 (on wlan0)
 TSF: 191896339578 usec (2d, 05:18:16)
 freq: 2412
 beacon interval: 100
 capability: IBSS Privacy (0x0012)
 signal: -55.00 dBm
 last seen: 288 ms ago
 SSID: adhoc
 Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
 DS Parameter set: channel 1
 ERP: <no flags>
 Extended supported rates: 6.0 9.0 12.0 48.0
 WPA: * Version: 1
   * Group cipher: TKIP
   * Pairwise ciphers: Use group cipher suite
   * Authentication suites: 00-50-f2:0
   * Capabilities: 16-PTKSA-RC (0x000c)

However, NM happily connects to the network without the host blocking the connection; with an invalid passphrase. (I used "12345678" entered on the "client"). See attached.

Using static IP addresses to configure both, they are mutually reachable which proves they are associating to the same BSSID.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

@mathieu-tl Stock Android does not support ad hoc wlan. See here http://code.google.com/p/android/issues/detail?id=82 (Second most stars of all issues there)

There are some custom roms like Cyanogenmod7 that support ad-hoc. And there are ways to replace wpa_supplicant manually with a version that supports ad hoc.

I will try to test it with an ISO of earlier release of ubuntu and save some information.

As a note to myself or developers who might be working on the issue:

nl80211: Join IBSS request sent successfully
wpa_driver_nl80211_set_key: ifindex=3 alg=2 addr=0x495e2c key_idx=0 set_tx=1 seq_len=6 key_len=32
nl80211: set_key failed; err=-67 Link has been severed)
Cancelling authentication timeout
State: ASSOCIATING -> COMPLETED

I don't know if it's relevant to the security being broken, but just in case it's worth re-testing with wext, and seeing if it reacts the same way.

wext fails in a similar way:

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
netlink: Operstate: linkmode=-1, operstate=5
wpa_driver_wext_associate
wpa_driver_wext_set_drop_unencrypted
ioctl[SIOCSIWGENIE]: Operation not supported
wpa_driver_wext_set_psk
Association request to the driver failed
wpa_driver_wext_set_key: alg=2 key_idx=0 set_tx=1 seq_len=6 key_len=32
Cancelling authentication timeout
State: ASSOCIATING -> COMPLETED

I checked the behaviour of previous releases with LiveCDs.
On 11.04 creating a WPA WLAN leads to an open network.
On 10.10 I saw a WEP secured net (in Wifi Analyzer, Android) but the connection information in Ubuntu said WPA.

I think it's the behaviour or Ubuntu 10.10 which led me to think it worked in a previous release, because I was asked for a password, but I wasn't aware, that it wasn't WPA but WEP. I'm sorry for the confusion.

Adding the nm-applet task because we'll be adding code in both NM and nm-applet to workaround this.

FWIW; it's indeed been broken for a while: http://thread.gmane.org/gmane.linux.kernel.wireless.general/87543/focus=87554

This bug was fixed in the package network-manager - 0.9.4.0-0ubuntu1

---------------
network-manager (0.9.4.0-0ubuntu1) precise; urgency=low

  * New upstream release 0.9.4.0: (LP: #960494)
    - settings: quiet warning when checking for AdHoc WPA connections
    - core: suppress useless log message when route already exists (LP: #958519)
    - TODO: remove bridging/bonding and InfiniBand
    - core: do a better job of applying bond configuration
    - libnm-util: improve NMSettingBond:verify()
    - libnm-util: fix an NMSettingBond bug
    - core: fix NMDeviceBond:dispose() to chain up
    - wifi: work around more wl.o stupidity
    - ip6: fix setting default route with libnl3 (bgo #668286)
    - firewall: set interface zone before IP configuration (rh #805405)
    - libnm-glib: ensure bindings-created objects work as expected (rh #802536)
    - mobile: ensure IPv4 timeout fails activation
    - utils: override VPN plugin's never-default when ignoring auto routes
    - wifi: make sure we're connected to netlink before using it
    - libnm-glib: add 'registered' property for NMSecretAgent
    - keyfile: fix testcases after InfiniBand transport-mode default change
    - wifi: disable Ad-Hoc WPA connections (LP: #905748)
    - infiniband: fix missing sentinel
    - Add a workaround for a problem creating InfiniBand connections
    - core: treat missing IPv6 setting as AUTO
    - libnm-glib: add errors to nm_device_connection_compatible() and device
      classes
    - vpn: add a new field so VPN plugins can specify multiple domains
    - dnsmasq: allow proxying dnssec data (upstreamed Ubuntu patch)
    - gsm: pass the PPP auth preferences for STATIC and DHCP device use
    - core: allow IPv4 to fail by default
  * debian/control: add Pre-Depends as required for maintscript.
  * debian/control: bump debhelper Build-Depends to (>= 8.1.0~).
  * debian/control: bump Standards-Version to 3.9.3.
  * debian/copyright: update copyright and migrate to format 1.0; thanks to
    Michael Biebl for the work. (LP: #907294)
  * debian/patches/nm-change-dnsmasq-parameters.diff: refreshed.
  * debian/patches/dnsmasq-dnssec-passthrough.patch: dropped, applied upstream.
  * debian/patches/nl3-default-ip6-route.patch: dropped, applied upstream.
  * debian/libnm-glib4.symbols: add new symbols:
    + nm_device_connection_compatible@Base
    + nm_device_*_error_get_type@Base
    + nm_device_*_error_quark@Base
    + nm_secret_agent_get_registered@Base
  * debian/network-manager.postrm: cleanup timestamps and seen-bssids files on
    purge.
  * debian/network-manager.{pre,post}inst: clean up and remove old migration
    steps; we can reimplement just the ones we need in maintscript.
  * debian/network-manager.maintscript:
    - fix the migration of /etc/dbus-1/system.d/NetworkManager.conf to its new
      name /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf, so we do
      not have leftover files after upgrade.
    - reimplement the rename of nm-system-settings.conf to NetworkManager.conf
      in this format (Debian has already done so).
  * debian/patches/git_doc_fixups_54618a7.patch: fix building documentation to
    make sure the documentation pages aren'...

Forgot to add the same bug tag to close the bug with the network-manager-applet, but it now also contains code to fix adhoc WPA. We can close this as Fix Released.

Joseph, why have you changed the status to Incomplete? Should we report another bug about the kernel or what additional info do we need? Are there any upstream kernel bug about this?

Seems like this currently is being worked on by the Fedora developers:

http://fedoraproject.org/wiki/Features/RealHotspot

Philipp Gassmann, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.