Android technical articles

Wi-Fi Direct

Why Wi-Fi Direct can not replace Ad-hoc mode

Wi-Fi Direct vs Ad-hoc mode

In this article we describe the basics of Wi-Fi Direct ("P2P"), point out the differences to Ad-hoc ("IBSS") mode and explain why Wi-Fi Direct can not substitute Ad-hoc mode.

Both, Ad-hoc mode and Wi-Fi Direct allow devices to connect directly to each other in a peer-to-peer way, without the use of a traditional Access Point. While Wi-Fi Direct is marketed as a replacement of Ad-hoc mode, and is claimed to be "much more secure" and easier to set up, it does not cover all possibilities of Ad-hoc mode: most importantly the capability to form larger-scale networks. And it comes at the cost of more complexity and only works well in limited situations. But let's have a look on both protocols first.

What is Wi-Fi Direct (P2P)?

Wi-Fi Direct™ is not an IEEE standard, but a Wi-Fi Alliance technical specification called "Wi-Fi Peer-to-Peer (P2P) Specification". It allows Wi-Fi devices to connect to each other and form groups, usually one-to-one, but also one-to-many. Wi-Fi Direct devices negotiate their roles in the connection: one of them assumes the traditional role of Access Point (AP) called Group Owner (GO) and the other devices, including non-Wi-Fi Direct enabled devices, connect to the AP/GO as clients in station mode. While we will argue below that this is not true peer-to-peer in the usual meaning of the phrase, we follow the term "P2P" as it is used in the specification in the rest of this description.

Wi-Fi Direct has some minimal requirements like the use of 802.11g, RSN (WPA2) with AES-CCMP encryption, Wi-Fi Protected Setup (WPS), WME (WMM) quality of service, and OFDM data rates for management frames. P2P devices use their global MAC address as Device ID during discovery and negotiation, and a temporary local MAC address for all frames within a group. Action frames and additional Information Elements (IE) are used to transport the details of the protocol.

1) Device discovery

Before any connection can be formed, P2P devices have to find each other. For this they alternately listen and send probe requests with additional P2P information elements on so-called social channels, which are channels 1, 6 and 11 in the 2.4GHz band. Unconnected P2P devices and Group Owners reply to them with probe response frames which also include P2P information elements describing the device and group characteristics. Group Owners respond in place of devices which are part of their group, but clients may choose not be be discoverable while they are connected to a group.

Device characteristics include:

  • User-defined device name (e.g. "My Printer")
  • Device type (e.g. "Media Server", "Smartphone", "Television", "Printer")
  • Supported WPS configuration methods (PIN, or PushButton)
  • Supported operating channels
  • Are additional connections supported?
  • Is service discovery supported?

Group characteristics include:

  • Can more devices join the group (group-limit)?
  • Is data exchange between clients provided? If yes, a device may join the group to communicate with any of the devices in the group (intra-BSS)
  • Does GO provide a connection to another WLAN or the Internet (cross-connection)?
  • Is this a persistent group?

2) Service discovery

After a P2P device has been discovered, and before establishing a group with it, it can be asked to describe the services it provides. This is an optional frame exchange which supports different service description protocols, such as "Bonjour" (DNS-SD), UPnP or WS-Discovery. After that, the application or user may choose to connect to a device based on its name or provided services, e.g. a camera may automatically connect to a display to show its photos, or a user may choose to connect to "My Printer" to print a document.

3) Group formation

If a device wants to connect to another, it can send a P2P Invitation request to a device which is already connected to ask it to join a new group, or it can directly start the formation of a group with an otherwise unconnected device by sending a GO Negotiation request.

Any P2P device can take the role of P2P Group Owner (GO) or P2P Client but the roles in the group are negotiated. The main purpose of this negotiation is to determine which of the two participating devices will become the GO and to exchange some characteristics of the group, like the operating channel, the WPS configuration method, and whether the group is a persistent group. Devices can communicate their willingness to become group owner with the GO Intent attribute (0-15) of the GO Negotiation request/response frames, and may refuse to form a group if the parameters of the group are not acceptable. By specification, group formation should be completed in less than 15 seconds, but since normally the user is required to enter a PIN code, or push a button, it can take more time.

After the decision has been made which device will become the Group Owner, a GO Negotiation confirmation is sent and both devices move to the negotiated operating channel. The GO starts to operate in Access Point mode, sending beacons with the negotiated SSID and a group formation bit set to 1, because the group formation has not yet been completed. The SSID is standardized to be "DIRECT-xy..." with xy being random characters/numbers and any postfix.

4) Provisioning and Encryption

Now the provisioning phase begins, where the client connects to the GO to exchange credentials with the WPS protocol, which is an exchange of eight EAP messages. To allow the connection, the user normally has to enter a PIN code or push a button on the device.

When joining an existing group, or to speed up the provisioning phase later, devices can send Provision Discovery request/response frames before starting the group negotiation. If not, the GO Negotiation may fail and have to be restarted when the user has taken more time than expected.

After that, the normal RSN (WPA2) 4-way handshake begins to exchange the encryption keys, where the GO assumes the role of authenticator and the client is the supplicant. Then the client will request a IPv4 address from the GO, which is required to implement an DHCP server, and finally actual data transfer can happen.

To avoid users having to enter a PIN code every time when a group is formed regularly between some devices, the group can be made persistent, in which case the devices  store the credentials and can automatically re-connect when required. A persistent group may use a different channel and device MAC addresses for each session.

4) Power Management

Wi-Fi Direct also describes some extensions to the 802.11 and WME power management: Opportunistic Power Save (OppPS) allows the GO to sleep in periods where all clients are in Power Save mode. Also the GO may send a Notice of Absence (NoA) in its beacons or in direct action frames to announce the fact that it will be absent for some period of time because it is sleeping or doing some work on another channel. Clients which have important traffic or specific delay requirements can send a P2P Presence Request to its GO which may or may not adapt its power save behavior.

5) Optional features: Concurrent operation and Manageability

The P2P specification mentions that P2P devices may support concurrent operation as multiple MAC entities, possibly on different channels, and thus could be part of more than one P2P group or WLAN simultaneously, but it does not further describe this option. We assume that current (2013) Wi-Fi chipsets may support two concurrent connections at the time, possibly more later.

Another optional feature of Wi-Fi Direct is the manageability of P2P devices in enterprise environments. The managed enterprise AP has the possibility to restrict P2P devices in its vicinity by limiting their allowed channels or transmit power and it can also disallow them to provide cross-connections into the corporate WLAN.

6) Frame exchange sequence

Now, let's look at an example frame exchange, where two Wi-Fi Direct devices "A" and "B" are discovering each other and form a group... Wi-Fi Direct supports many different scenarios, but we assume that this is the most common case.

At first both devices will enter the scan phase, and send

A arrow-right B (1) Probe requests with P2P IE on all channels.

After a random time one of them will start to listen on one of the social channels (1, 6 or 11) and finally receive a probe request from the other station. It will reply with:

A arrow-left B (2) Probe response with P2P IE

Device A reports "Another device found" to the user or managing application. Now an optional service discovery exchange can happen:

A arrow-right B (a) Service Discovery query
A arrow-left B (b) Service Discovery response

We don't count this optional frame exchange to have a fair comparison to Ad-hoc mode later.

Then group formation begins:

A arrow-right B (3) GO Negotiation request

B reports this to the user and will wait for the input, which we assume to timeout in this case.

A arrow-left B (4) GO Negotiation response (fail)

Optionally, instead of having the first GO Negotiation fail, the devices could have used Provision Discovery before group formation, but this does not change the number of total frames exchanged:

A arrow-right B (3) Provision Discovery request
A arrow-left B (4) Provision Discovery response

A arrow-right B (5) GO Negotiation request

In the end we suppose the user on B has allowed the connection.

A arrow-left B (6) GO Negotiation response (success)
A arrow-right B (7) GO Negotiation confirmation

Now one device becomes GO and the other client, Let's assume B is the GO

A arrow-left B (8) GO sends beacons (formation bit = 1)
A arrow-right B (9) Authentication 1
A arrow-left B (10) Authentication 2
A arrow-right B (11) Association request
A arrow-left B (12) Association response

Now the "provisioning" phase begins, which is a WPS exchange of usually 8 frames. We don't go into the details of the WPS protocol here.

(13) (14) (15) (16) (17) (18) (19) (20)

Next the GO starts to send beacons with the formation bit set to 0.

A arrow-left B (21) GO beacon (formation bit = 0)

The client re-authenticates and re-associates with the new credentials:

A arrow-right B (22) Authentication 1
A arrow-left B (23) Authentication 2
A arrow-right B (24) Association request
A arrow-left B (25) Association response

Now the RSN 4-way handshake begins, and again we don't go into the details of RSN:

A arrow-left B (26) ANonce
A arrow-right B (27) SNonce + MIC
A arrow-left B (28) GTK + MIC
A arrow-right B (29) ACK

After that we can exchange data frames in the group, but usually the DHCP protocol will be used first to provide the client with an IP address. Again, we don't count these frames to have a better comparison to Ad-hoc mode.

At least 29 frames had to be exchanged before the first data transmission. In the case of two devices re-invoking a persistent group, we need at least 18 frames.

Ad-hoc (IBSS) mode

Ad-hoc mode is officially called IBSS (Independent Basic Service Set) in the IEEE 802.11 standard, and contrary to what some people believe is neither "legacy" nor inherently insecure - it's an active part of the current IEEE802.11-2012 standard, which states that "IBSS is the most basic type of IEEE 802.11 LAN". All standard-compliant devices should implement it. In comparison to Wi-Fi Direct, IBSS mode is very simple, but let's recapitulate how IBSS mode functions:

1) Ad-hoc network formation

Any device can start an IBSS, and there is no hierarchy between IBSS devices, which is why we usually call an IBSS device just "node".

A device wishing to join an IBSS with a certain name (SSID) will scan to see if the network already exists, by passively listening on the channel and receiving beacons from other nodes or by sending probe requests. If an existing IBSS is detected its BSSID is taken over and data frames can be exchanged directly between all IBSS nodes within radio reach.

2) Beaconing

Just as APs, IBSS nodes regularly send beacons, containing the network name (SSID), a BSSID and a timer value (TSF) to announce the existence of the IBSS network. In order to save bandwidth, devices in the same IBSS share the task of sending beacons: if a node already received a beacon from another device within one beacon period, it will itself refrain from sending a beacon this period. Random back-off intervals ensure that every device gets its chance to send a beacon every once in a while. In order to be backwards-compatible to 802.11b, the beacons and management frames are sent at low data rates (1 or 2 Mbps) by default, but any good driver implementation will let us choose the basic rates so we can also use only OFDM rates just as Wi-Fi Direct.

3) IBSS merge

There is only one tricky case in IBSS mode, which is called "IBSS merge" or "IBSS coalescing", which is when two or more nodes with the same network name (SSID) have previously chosen different BSSIDs, possibly because they were not within reach of each other, but now they are joining. You can imagine a group of inter-connected smartphones coming into a room where another group of devices is using the same IBSS. In this case, the rule is that the "younger" IBSS has to take over the BSSID of the "older" IBSS. The age of an IBSS is know by the TSF timer values sent in the beacons. This rule is described in the 802.11 standard but it takes some reading between the lines to figure out how to properly implement it, and this is the reason why some drivers and firmwares have had problems with IBSS mode in the past.

4) Security

There is no standard requirement for security in IBSS mode, so IBSS networks are free to choose between using no encryption, WEP, WPA or RSN (WPA2). So, same as APs and Wi-Fi Direct, Ad-hoc mode can also be used with RSN (WPA2) pre-shared keys, although support for this has just been added recently in Linux. For exchanging the encryption keys, all IBSS devices have to make the 4-way handshake between each other.

It is not uncommon for some Ad-hoc networks, like community or disaster recovery networks to use no encryption on the network layer, leaving it to higher layers (for example OpenVPN or the application protocol) to implement encryption when desired.

5) Frame exchange sequence for an IBSS with RSN

Let's look at the frame exchange sequence of two nodes forming an IBSS which is using IBSS-RSN to provide RSN encryption and thus the same level of security as a Wi-Fi Direct group.

First, the joining device may scan to find an already existing IBSS:

A arrow-right B (1) Probe request
A arrow-left B (2) Probe response

Then open authentication may be used:

A arrow-right B (3) Authentication (open)
A arrow-left B (4) Authentication (open)

After that we see the RSN key exchange from A to B:

A arrow-right B (5) ANonce
A arrow-left B (6) SNonce + MIC
A arrow-right B (7) GTK + MIC
A arrow-left B (8) ACK

And then the key exchange in the other direction:

A arrow-left B (9) ANonce
A arrow-right B (10) SNonce + MIC
A arrow-left B (11) GTK + MIC
A arrow-right B (12) ACK

In this case we had to exchange 12 frames before actual data traffic can be exchanged. If encryption is not used, we can exchange data right away, after receiving a probe response or beacon from the other node, as the authentication and probe request frames are optional.

Depending on the setup of the Ad-hoc network, DHCP can be used to provide IP addresses, but due to its distributed nature Ad-hoc networks are usually configured with static IP addresses, IPv6 or other by methods.

Topology scenarios

Let's play through some topology examples, in scenarios where Wi-Fi Direct is targeted and marketed. We assume that the involved Wi-Fi Direct devices do not support concurrent operation.

1) Home media center

Let's say I have the latest Wi-Fi Direct enabled Miracast™ television in my living room, and I connect my smartphone to it to control the content shown. The video I am watching is streamed to the TV from a media server or NAS which is connected to the same Wi-Fi Direct group. As it happens, the smartphone can not directly see the media server and the TV is the group owner.


Now, someone else in another room wants to connect to the media server to view some photos on a tablet. Unfortunately the tablet is too far away from the TV, so it can not just simply join the existing group (if the TV allowed intra-BSS traffic it would exchange data on behalf of the tablet and media server).

Now we have two options, both of which lead to a fragmented network and an unpleasant user experience:

a) The tablet sends an P2P Invitation to the media server, but it refuses to join another group, since it is already connected to the TV. The tablet can not connect and see the photos.


b) The tablet sends an P2P Invitation to the media server and the server chooses to form a new group with the tablet where it ends up being the GO. The TV could try to re-negotiate its group membership with the new GO to resume the video stream, after a half-minute delay, if at all possible (the TV may require to be GO).


The smartphone is locked out of the group and can not enjoy the benefits of Miracast™ any more.

Ad-hoc mode

In the case of an Ad-hoc network, the tablet would be able to connect to the media server independently of the other devices, obviously having to share the available bandwidth at the server with the ongoing video stream to the TV. All participants could enjoy the desired functionality.


2) Mobility

Another problematic case for Wi-Fi Direct is mobility or when the GO disappears. Then, the group has to be re-negotiated and this will lead to service disruption if devices are using the connection at the moment. Also as we have seen earlier each group negotiation is approximately 29 frames, which can require a lot of bandwidth, especially with interference, lost frames and many retries, which is usually the case in highly mobile scenarios.

Let's consider the following example, and let's assume that the devices always try to maintain a connection, for example because they use the Internet cross-connection, or because some higher-level protocol wants to exchange data between all devices.

Again, let's assume I am at home, connected to my modern Wi-Fi Direct TV which is GO, provides me with Internet and also a connection between my smartphone and the smartphone of my wife, which we use to exchange a large amount of holiday photos.


While the synchronization happens, we realize that we forgot something in the car, and move there with both phones. After leaving the house the GO is not in reach, so the smartphones have to negotiate a new group between each other, in the attempt to keep synchronizing. That will take some time and unfortunately may configure different IP addresses than before, which applications usually don't react to well.


Now, at the car, a persistent Wi-Fi Direct connection to the cars navigation system is re-invoked for both phones, again resulting in group negotiation frames, different IPs and the loss of the application connection.


On the way back, the same thing happens again, and basically we have to re-start the photo synchronization many times.

Ad-hoc mode

In the case of Ad-hoc mode, no connections have to be negotiated and data can be exchanged just as the radio transmission allows, so as they move together, the two smartphones could always keep synchronizing. When the TV or car is in reach its services could be used without requiring re-configuration of the smartphones.

3) Other scenarios

While the examples above might seem artificial, we can imagine many similar or more complex situations where Wi-Fi Direct does not work well. We know from experience that any problematic topology will happen at some point and that the frame exchanges caused by many re-configurations can eat up the limited available bandwidth quickly. Also interference or moving objects can cause mobility scenarios even though the devices are static, which means that groups may have to be re-negotiated frequently as devices come and go into each others reach. This can disrupt the service as we have seen above, and while that may be annoying but acceptable to some extent for personal usage, it is usually not acceptable in more critical or business applications.

If the Wi-Fi Direct devices would support concurrent operation, they could solve the topology scenarios described above, but fail at more complex ones - independently of the number of possible concurrent connections there will always be some limit and some topology which can not be supported. Also concurrency can not solve the problem of topology changes and the resulting re-negotiations of groups which can cause service disruption, which we believe may be the worst problem of Wi-Fi Direct from a usability point of view.

Comparison between Wi-Fi Direct (P2P) and Ad-hoc (IBSS) mode

If we take the definition of peer-to-peer (P2P) which is "Peers are equally privileged, equipotent participants in the application" we have to conclude that Wi-Fi Direct, despite its name "P2P", is not a real peer-to-peer protocol. It is essentially a protocol for forming hierarchical groups, and mostly used to connect just two devices. The devices are only equal peers until they connect to each other, and one of them becomes group owner. After that they follow the hierarchical roles of AP and client - master and slave. While the protocol, especially in combination with service discovery can provide a convenient and secure way to temporarily connect two devices, like a camera to a printer, it does not scale beyond a few devices in close proximity.

On the other hand, the comparatively old, simple, and often neglected Ad-hoc (IBSS) mode is a true peer-to-peer solution with no hierarchies, where all participants are equal. This opens up a wide range of possibilities and communication modes, among them opportunistic, delay-tolerant networking and large-scale mesh networks, which are especially useful in scenarios where local infrastructure is untrusted or unavailable. But because IBSS mode is so simple and has many configuration options, it can be difficult to use. Even though we have shown examples where plain IBSS mode has advantages over Wi-Fi Direct in some application-scenarios, it can show its real strength only in combination with higher-layer protocols which implement IP allocation, service discovery, encryption, and possibly multi-hop forwarding.

Benefits of Wi-Fi Direct
  • Easy to use for temporarily connecting a few devices
  • Security and encryption is built into the protocol
  • Service discovery is part of the protocol, although optional
                    Benefits of Ad-hoc mode
  • Real peer-to-peer solution
  • Can handle dynamic topology changes
  • Enables large-scale mesh networks
  • Simple protocol
  • No extra frames need to be exchanged before data traffic
Drawbacks of Wi-Fi Direct
  • Some topologies are not supported
  • Does not respond well to dynamic topology changes
  • Complex protocol
  • Many frames need to be exchanged before data traffic
  Drawbacks of Ad-hoc mode
  • Difficult to use for unexperienced users
  • All nodes in the network are on the same channel
  • No built-in security or encryption
  • No built-in service discovery


Finally we conclude that Wi-Fi Direct and Ad-hoc mode solve very different use-cases and one can not replace the other. Wi-Fi direct is made for temporarily connecting a few devices in an easy-to-use and secure way, but it does not work well for larger network topologies. IBSS mode is more versatile and difficult to set up, but can be used together with higher level protocols to form large-scale mesh networks. To use the term peer-to-peer equally for both solutions is misleading since it leads to the assumption that the limited form of "P2P" of Wi-Fi Direct could substitute the real P2P capability of Ad-hoc mode, which is not the case.

Android IBSS


Ad-Hoc (IBSS) mode support for Android 4.2.2 / 4.3 / 4.4 / 5.0


This page provides information about the status of integrated Ad-Hoc (IBSS) mode support in Android and documents our development effort.

We have created patches to bring the missing Ad-Hoc (IBSS) mode to Android, in a way that is fully integrated into the Android system API and user-interface. Using them, we are able to create and connect to Ad-Hoc networks from the standard user interface (Settings - WiFi) and Applications have an API to configure their "own" Ad-Hoc network (allthough tru reflection until the changes are officially accepted in AOSP). We believe this will help people who need more capabilities than WiFi Direct (also read this article on the limits of WifiDirect) and that this can extend diverse usages of Android mobile devices.

In more detail, we have modified the WLAN driver "bcmdhd", extended the Android framework, the public Android API and added the missing parts to the "Settings" application. We are only testing Nexus S, Galaxy Nexus and Nexus 7 devices, but a few more devices are supported in CyanogenMod. Once a device kernel WiFi driver supports Ad-Hoc mode, the UI will automatically show Ad-Hoc mode options.

We originally based our additions on CyanogenMod 10.1-M2 (Android 4.2.2 JDQ39) and Google AOSP Android 4.2.2 and have submitted all changes upstream. While our changes still have not been accepted in the official Google AOSP (with little feedback or explanations), they got merged into CyanogenMod from version 10.1.0 onwards and we continue to forward-port the changes to newer CyanogenMod and AOSP versions. The easiest way to get Android with Ad-Hoc mode support is to just install CyanogenMod.


21.01.2015: Ported to CyanogenMod 12: Our IBSS changes got forward ported to CyanogenMod 12 which is based on Android 5.0 "Lollipop". Nexus 7 is working fine, but CM-12 support for the older devices like Galaxy Nexus and Nexus S is still missing and may not be added (not sure, check the nightly builds).

13.03.2014: Ported to CyanogenMod 11: We just ported the UI changes to CyanogenMod 11 (CM-11), which got lost in the CyanogenMod rebase to Android 4.4. See the change here in CyanogenMod gerrit. It got merged and became part of the nightly build on 16.03. Also we rebased the changes for AOSP 4.4 and submitted to Google again (part1 and part2).

14.05.2013: New App to setup Ad-hoc networks thru reflection: We have updated the demo application for setting up Ad-hoc networks. It can now be built externally and installed on any device, as we are accessing the new methods thru Java reflection.

17.04.2013: Samsung Epic 4G kernel gets IBSS mode support in CyanogenMod. One more device :)

23.04.2013: Workaround for video queue problems on BCM4330: The BCM4330 chipset has problems in IBSS mode when packets are sent into the WME video queue (AC_VI). This affects all packets which have their DSCP priority set to 4 or 5 (TOS 0x80 and 0xa0) and the symptom is that these packets get lost, instead we see excessive RTS/CTS and sometimes this leads to a complete hang of the chip. Since the problem happens in firmware we can not do much except adding a simple workaround to downgrade the "video" priority to "best effort" (patch).

15.04.2013: CyanogenMod merged IBSS support for Nexus S, Galaxy Nexus and Nexus 7. Finally the IBSS support has been merged in the kernel of these devices and is available in CyanogenMod nightly builds. Also Channel/Frequency selection has been merged. So now the easiest way to get IBSS support is to use the nightly images from

28.03.2013: Added Channel/frequency selection to Settings for newly created Ad-Hoc networks. We provide new images which include these changes below. The new images also include the iw command line utility for debugging.

25.03.2013: CyanogenMod merged IBSS support for Samsung Galaxy S, Samsung Captivate, Samsung Vibrant and Samsung Fascinate,which makes these devices the first to actually get IBSS mode support thru the official CyanogenMod nightly build. ( 

24.03.2013: Framework merged in CyanogenMod: The changes to the framework got merged in CyanogenMod and are already part of the nightly builds! Still missing are the kernel changes. But this means you don't have to build the entire Android tree to try IBSS mode on another device - you can download the latest nightly build and then only patch and build the kernel for your device. Let us know if you succed on any device not mentioned here!

Download and usage

We repeat, nowadays the easiest way to get Ad-Hoc mode support is to download CyanogenMod for the supported devices. For reference we provide our original CyanogenMod 10.1-M2 based system images which you can install as usual (using ClockworkMod recovery, and "install zip from sdcard") if you want to try our IBSS mode changes:

The following devices have Ad-hoc mode support thru CyanogenMod, which you can download from

  • Samsung Galaxy S, Samsung Captivate, Samsung Vibrant and Samsung Fascinate ("aries")
  • Nexus 7 ("grouper")
  • Galaxy Nexus ("maguro")
  • Nexus S ("crespo")
  • Samsung Epig 4G ("epicmtd")

After installation, you can see existing Ad-Hoc networks in the list of networks in Settings - Wi-Fi. This screenshot shows this and that we are already connected to an Ad-Hoc network:

You can also create a new Ad-Hoc network using the "+" (Add) button. The "Ad-Hoc (IBSS) Network" option is hidden under "Show advanced options":

Screenshot Adhoc-Add2

Showing existing Ad-Hoc network connection details:

Screenshot Adhoc-Connect2

Another way to use the new features is to try the AdhocConfigDemo App below, or use similar code in your own App to automatically configure your own Ad-Hoc network.

Building and patches


Building based on CyanogenMod 10.1-M2

We built our images based on CyanogenMod 10.1-M2. Please follow the CyanogenMod instructions for checking out the sources and building.To use the M2 tag check out using the following repo commands:

repo init -u git:// -b cm-10.1
repo init -m cm-10.1-M2.xml
repo sync

You can also use the latest cm-10.1 branch of CyanogenMod (not M2) but then you will need to check yourself which of our changes are already included and which are not.

After you have synced all sources and before applying the patches, you need to run the breakfast command to download the kernel sources. Then you can optionally initiate new branches:

repo start IBSS external/wpa_supplicant_8 frameworks/base packages/apps/Settings

And depending on which kernels you are building:

repo start IBSS kernel/asus/grouper kernel/samsung/tuna kernel/samsung/crespo

Here is a patch that includes all changes: IBSS-all-in-one.diff (includes all patches below) - you can apply it at the top CyanogenMod directory.

patch -p1 < IBSS-all-in-one.diff

Otherwise you can apply all separate patches by going into the respective subdirectories and typing "git am patchname", or better by pulling them from the CyanogenMod Gerrit by using the commands from the links below, for example:

git pull refs/changes/35/34635/1

The kernel patches are all essentially the same, with just line number changes. If you are building for another device which has a Broadcom chipset, you can try to apply it to your kernel tree, for example:

cd kernel/acer/t30
patch -p1 < kernel-asus-grouper-0001-bcmdhd-Enable-Ad-Hoc-IBSS-mode.patch

Using CyanogenMod nightly builds

Since the changes have been included into CyanogenMod, the system is ready for Ad-Hoc mode, but the options will only be shown if the kernel driver supports IBSS mode. See the list above to see which devices come with Ad-Hoc mode support by default.

If your device is not yet supported but has a Broadcom chipset and uses the "bcmdhd" driver, chances are that you can apply one of the kernel patches listed above (e.g. this one). You then re-compile the kernel, create a boot.img and boot into it. Inside the CyanogenMod tree this works like this:

make bootimage
adb reboot bootloader
fastboot boot out/target/product/grouper/boot.img

Note that unfortunately there are many different "bcmdhd" driver versions in different device trees, and one some the patch alone is not enough.


Below we provide the links to the changes in CyanogenMod and AOSP Gerrit and "upstream" if available. Please note that the patches submitted to CyanogenMod do NOT change the public API, as this is not allowed by CM policy, but the local ones and the ones submitted to AOSP do, since we want to change the public API in the long run.

Local patch
CyanogenMod Gerrit AOSP Gerrit Upstream


33720 (merged) 53582 merged hostap
external-wpa_supplicant_8-0002-Add-capability-flag...patch 33721 (merged) 53583 merged hostap
frameworks-base-0001-Wifi-Enable-Ad-Hoc-IBSS-net...patch 33722 (merged) 53580 AOSP
frameworks-base-0002-Wifi-Add-IBSS-supported-method.patch 33723 (merged) 53581 AOSP
packages-apps-Settings-0001-Wifi-Allow-configuration-of-Ad-H...patch 33727 (merged) 53584 AOSP
packages-apps-Settings-0002-Wifi-Enable-IBSS-options-only-if...patch 33728 (merged) 53585 AOSP
kernel-samsung-tuna-0001-bcmdhd-Enable-Ad-Hoc-IBSS-mode.patch 33726 (merged) n/a  
kernel-samsung-crespo-0001-bcmdhd-Enable-Ad-Hoc-IBSS-m...patch 33725 (merged) n/a  
kernel-asus-grouper-0001-bcmdhd-Enable-Ad-Hoc-IBSS-mode.patch 33724 (merged) n/a  
external-wpa_supplicant_8-0003-Include-frequencies-in-get_ca...patch 34633 (merged) n/a submitted hostap
frameworks-base-0003-Wifi-Get-the-list-of-supported-channels.patch 34634 (merged) 54793 AOSP
packages-apps-Settings-0003-Wifi-Add-frequency-selection-fo...patch 34635 (merged) 54794 AOSP
kernel-samsung-tuna-0002-bcmdhd-workaround-broken-AC-video...patch 36383 n/a  
kernel-asus-grouper-0002-bcmdhd-workaround-broken-AC-video...patch 36382    

Technical Details

Kernel driver

Obviously support for IBSS mode is something that has to come from the kernel WLAN driver in the first place. We have enabled IBSS mode in the "bcmdhd" driver which is the driver for many Broadcom chipsets. Luckily most of the functionality is already there and we just have to enable Ad-Hoc mode. The most important part of the patch is therefore already well known to the community:

+++ b/drivers/net/wireless/bcmdhd/wl_cfg80211.c

The rest is just dealing with statistics gathering to show signal strength in the status bar. Here are the patches for grouper (Nexus 7), tuna (Galaxy Nexus) and crespo (Nexus S). They are all essentially the same and just may have different line numbers.

Broadcom is not the only chipset used by Android devices, but we are concentrating on it because most of the Nexus line devices have a Broadcom chipset and use the same "bcmdhd" driver. The devices we have tested so far are:

Device Chipset Bands driver driver version Status
Nexus 7 BCM4330 b/g/n (2GHz) bcmdhd Merged CyanogenMod, tested by Thinktube
Galaxy Nexus BCM4330 a/b/g/n (2GHz, 5GHz) bcmdhd Merged CyanogenMod, tested by Thinktube
Nexus S BCM4329 b/g/n (2GHz) bcmdhd Merged CyanogenMod, tested by Thinktube

Samsung Galaxy S, Samsung Captivate,
Samsung Vibrant, Samsung Fascinate

BCM4329 b/g/n (2GHz)? bcmdhd Merged CyanogenMod, User confirmed

Support for other kernels and other drivers may be added by fixing the driver and setting the same interface flag - if you do so, please let us know.


Android uses wpa_supplicant to manage the wireless network connections. wpa_supplicant can also be used to connect to or create Ad-Hoc networks.

We have had to add three minor modifications to wpa_supplicant, one to remember the frequency for newly created IBSS networks (PATCH1) and another to ask wether the driver supports IBSS mode (PATCH2) at runtime, so the User-Interface can dynamically show IBSS options only when the driver supports it. And a third one to get the list of available frequencies (PATCH3).

Note that contrary to common believe we have found that AP_SCAN=2 is not necessary, at least for the drivers above.

Android framework and API

The next part was to add the necessary bits to the Android framework, which is mostly passing the necessary configuration (mode and frequency) to wpa_supplicant and asking wpa_supplicant wether the driver supports IBSS mode. We are trying to push these API changes thru AOSP.

We have added the following to the public Android API:

  1. WifiConfiguration
        public boolean isIBSS;
        public int frequency;

Which represent the respecive configuration options (PATCH1).

  1. WifiManager
        public boolean isIbssSupported();
        public List<WifiChannel> getSupportedChannels();

Which can be used to ask wether the driver supports IBSS mode (PATCH2) and to get the list of available frequencies (PATCH3).

Note that we can only expect a valid result after WifiManager.WIFI_STATE_ENABLED has been reached. This is due to the internal state machine handling in WifiStateMachine: we can not expect wpa_supplicant to be running or drivers loaded at all times.

Android Settings App

Using these modifications to the framework we extended the standard "Settings" App to let us connect to and create Ad-Hoc networks as shown in the screenshots above. Also here our modifiation has three parts:

  • Add IBSS mode options in the GUI (PATCH1)
  • Enable them only when IBSS mode is supported by the driver (PATCH2),
  • Allow frequency selection for new IBSS networks (PATCH3)

Configuring Ad-Hoc mode from your own App

Using our changes we can configure Ad-Hoc networks from Applications, but the problem is that the API is not (yet?) official, so we have to use Java reflection to access the new fields. We also have to use the same method to configure static IP addresses, since there is no public API for that as well.

Here is the relevant part of the source code:

    /* We use WifiConfigurationNew which provides a way to access
     * the Ad-hoc mode and static IP configuration options which are
     * not part of the standard API yet */
    WifiConfigurationNew wifiConfig = new WifiConfigurationNew();

    /* Set the SSID and security as normal */
    wifiConfig.SSID = "\"AdHocDemo\"";

    /* Use reflection until API is official */

    /* Use reflection to configure static IP addresses */
    wifiConfig.setIpAddress(InetAddress.getByName(""), 24);

    /* Add, enable and save network as normal */
    int id = mWifiManager.addNetwork(wifiConfig);
    if (id < 0) {
        log("Failed to add Ad-hoc network");
    } else {
         mWifiManager.enableNetwork(id, true);

WifiConfigurationNew provides an interface to the new config options which internally uses reflection:

   private Class<?> wc;    public WifiConfigurationNew() {
        wc = this.getClass();

    public void setIsIBSS(boolean val) throws NoSuchFieldException, IllegalArgumentException,
            IllegalAccessException {
        Field fIsIBSS = wc.getField("isIBSS");
        fIsIBSS.set(this, val);

    public void setFrequency(int freq) throws NoSuchFieldException, IllegalArgumentException,
            IllegalAccessException {
        Field fFreq = wc.getField("frequency");
        fFreq.set(this, freq);

We can only check for IBSS support after WifiManager.WIFI_STATE_ENABLED has been reached, and therefore we have to register a BroadcastReceiver to catch the state change to it, and do the configuration after that, when we know that Wifi is enabled. See the source code below for details.

After running this App you can check in Settings -> Wi-Fi that an "AdHocDemo" network has been configured with a static IP address.

Download APK and Source code.


There are still many possible improvments and a lot of work to be done to support a wider variety of devices.

  • Test IBSS RSN
  • Add kernels and devices

Please let us know if you manage to patch the kernel and build for other devices than the ones mentioned above!

History, Background and References

Missing Ad-Hoc mode in Android has been a major obstacle to more innovative modes of networking with Android devices, from direct file-transfer between two devices without an AccessPoint, to Mesh networking and disaster operation (one example is the Serval Project). This is a real pity because with the networking and processing capabilities of modern smartphones, the original Mesh networking idea of many interconnected mobile devices forming networks in an "adhoc" way, comes so much closer.

The community requests for Ad-Hoc mode have been ignored for many years (bug 82, discussion), and so far there have been a few different attempts to make use of Ad-Hoc mode with Android. Most of these attempts try to add Ad-Hoc mode by installing a single App, but they require the device to be "rooted", and use the externally compiled and long deprecated "iwconfig" utility (WEXT). This limits their possibilities and therefore usefulness. We believe that it's better to move forward, extend the API and push Google to include it in AOSP. That's what we are trying here.

Nevertheless all these attempts show that there is a need for Ad-Hoc mode, and that the advertised Wifi Direct (P2P) can not always serve as a replacement for Ad-Hoc mode. To mention a few:

Also we have not been the first to do this, there was a similar attempt in 2010 (AOSP Gerrit 13291 and 13292) which was rejected due to an "ongoing internal ad hoc implementation that will conflict with this patch". So far this implementation has not surfaced, and the implementation in the Android version today is a bit different, but this patch has served us as a first hint where to look at.

Also there is another similar change in the AOSP review process: AOSP Gerrit 43070.

We want to show here that it is possible to add Ad-Hoc mode to the Android framework and we would like to join forces with all groups interested in this. Finally, our hope is that this IBSS mode changes can be integrated into the standard Android API in future versions, so at least the drivers which support IBSS mode can make use of it.


Please send us feedback and support the inclusion of IBSS mode in Android by making your voice heard in the Android bugtracker or groups.
Contact us with technical questions and comments.

Contact: Bruno Randolf (Thinktube Inc.)

Last update: 16 March 2014