928362 - Implementation of 802.11 (Wi-Fi) ad hoc feature

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Wifi, defect, P2)

Description

[_auzias]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130917 Firefox/17.0 Iceweasel/17.0.9 (Nightly/Aurora)
Build ID: 20130917135315




Expected results:

The 802.11 (Wi-Fi) ad-hoc feature is not supported neither Android nor iOS. However this feature is very powerful.

In general this can allow communication without any use infrastructure in cases such as :
 * Connectivity in developing area (India, Cambodia) [1]
 * Electronic health care [2]
 * Wildlife monitoring [3]
 * Urban monitoring
 * Undersea communication
 * Military applications
 * Emergency relief operations [4]

As you can see this field is a research domain developed and growing. Nonetheless its use for a global audience is not yet feasible, indeed we -the masses, the consumers- do not have any product (expect laptop, heavier than smartphone) supporting the DTN[5] features.

The implementation on our smartphones would make these use-cases possible :
 * Communication after a disaster (earth quake, terrorism attack) which destroyed infrastructure so the emergency service can organized themselves
 * Communication when a dictatorship shutdown usual communication ways
 * "Tribute communication", is it necessary to send data to a 4-klm-far antenna when you just when to send a "where R U?"-SMS to a 100-m-close friend ?
 * City-wide network with town-related information (buses timetable...)
Some mobile applications exist already[7].

So... Here is my question. Mozilla, will you implement this ad hoc feature ?

Please, make the difference with Android[6] or iOS. Thousand of consumers want and need it already.

[1] : http://www.firstmilesolutions.com/documents/DakNet_IEEE_Computer.pdf & http://www.slideshare.net/aditya127/daknet-full-ppt
[2] : http://www-irisa.univ-ubs.fr/CASA/Publications/Author/benferhat-en.html
[3] : http://academic.research.microsoft.com/Publication/17117/energy-efficient-computing-for-wildlife-tracking-design-tradeoffs-and-early-experiences-with
[4] : http://kfall.com/ucbpage/papers/dtn-iscram.pdf
[5] : Delay -/Disruption- Tolerant Network, http://www.dtnrg.org/wiki/Home
[6] : https://code.google.com/p/android/issues/detail?id=82
[7] : https://www-casa.irisa.fr/dodwan-expe/

Comment 1

[_auzias]

Are bug related :
https://bugzilla.mozilla.org/show_bug.cgi?id=821539 [SOLVED] :  Don't offer to connect to ad-hoc networks *better "create" one than "connect to"*
https://bugzilla.mozilla.org/show_bug.cgi?id=890261 [NEW] :  Support connecting to ad-hoc Wi-Fi network *looks alike the previous one*
https://bugzilla.mozilla.org/show_bug.cgi?id=811635 [NEW] :  B2G Wi-Fi: Support Wi-Fi Direct *imo, Wi-Fi direct is not better than bluetooth but Wi-Fi ad hoc is*

Comment 2

[_auzias]

NB : the opportunity of a new market will be also guaranteed with this feature. This OS is lighter than Android, then smartphone will be cheaper and in developing country, often without infrastructure, ad hoc application support Internet disruption will be an advantage to this new market.

Comment 3

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

1.3 is FC already.

Comment 5

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: [01] Bug 928362: Support ad-hoc mode for Wifi

Comment 6

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Make settings app indicate ad-hoc networks

With this patch, the Settings app adds the label 'Ad-hoc mode' to detected ad-hoc networks.

Comment 7

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Screenshot of Settings app

This shows the effect of the Gaia change. You can see that 'FirefoxNetwork' is labeled with 'Ad-hoc mode'.

Comment 9

[Thomas Zimmermann [:tzimmermann] [:tdz]]

We'll also need an interface for creating an ad-hoc network and setting a static IP address on the interface. DHCP works, but probably leads to problems in practice.

Comment 10

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8425481 [details] [diff] [review]
[01] Bug 928362: Support ad-hoc mode for Wifi

Review of attachment 8425481 [details] [diff] [review]:
-----------------------------------------------------------------

Does ad-hoc mode support depend on wpa_supplicant version or wifi driver ?

::: dom/wifi/WifiWorker.js
@@ +1492,5 @@
> +    return 0;
> +
> +  if (/\[IBSS/.test(flags))
> +    return 1;
> +  return 0;

How about isAdHoc or isIBSS ? Or you can specify the return value to IBSS/ESS/P2P.

Comment 11

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Vincent Chang[:vchang] from comment #10)
> Comment on attachment 8425481 [details] [diff] [review]
> [01] Bug 928362: Support ad-hoc mode for Wifi
> 
> Review of attachment 8425481 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Does ad-hoc mode support depend on wpa_supplicant version or wifi driver ?

In general ad-hoc mode should be supported by current Linux drivers and wpa_supplicant. I heard it's required to pass certain certification. The Linux drivers share a common framework, so I'd expect that ad-hoc mode is easy for most of them; wpa_supplicant just builds on top of that.

If there are incompatible devices, we could add an environment variable to disable support for ad-hoc mode.

Comment 12

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: [01] Bug 928362: Support ad-hoc mode for Wifi (v2)

Hi Vincent,

Sorry for the long delay. I updated the patch for the latest Trunk, added constants for the Wifi modes, and added an environment property for disabling Ad-hoc support on devices that don't support it. The patch allows my Nexus 4 to connect to an Ad-hoc network.

Changes since v1:

  - rebased
  - added constants for Wifi mode
  - added environment property 'ro.moz.wifi.ibss_supported'

Comment 14

[Alan K [:ack]]

https://github.com/mozilla/gecko-dev/blob/987e99e6f8ac28f7510234f48813a4b596c9857e/dom/wifi/WifiCommand.jsm#L352

We don't currently allow other values for AP_SCAN, which might be necessary for Ad-hoc mode. I'm able to set the BSSID with wpa_cli, but wpa_supplicant ignores it.

Comment 15

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8472852 [details] [diff] [review]
[01] Bug 928362: Support ad-hoc mode for Wifi (v2)

Review of attachment 8472852 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good for me. But we need DOM peer to review the webidl part. 
We need your help, mrbkap.

::: dom/wifi/WifiWorker.js
@@ +2324,4 @@
>                signalLevel = match[3],
>                flags = match[4];
>  
> +          /* skip networks with unknown or unsupported modes */

Nit: Capital letter in the beginning of the sentence and add period at end.

Comment 16

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: [01] Bug 928362: Support ad-hoc mode for Wifi (v3)

Changes since v2:

  - fixed comment

Comment 17

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: [02] WIP: Set AP_SCAN before adding network

This is a WIP patch for making (AP_SCAN != 1) work. I have been able to connect a Flame to an ad-hoc network and get a DHCP lease using wpa_cli. It still doesn't work with Gecko. When I try to connect the wpa_cli shows:

> > list_networks
> network id / ssid / bssid / flags
> 0	FirefoxNetwork	any	[CURRENT]
> <3>CTRL-EVENT-SCAN-RESULTS 
> <3>WPS-AP-AVAILABLE 
> <3>Trying to associate with SSID 'FirefoxNetwork'
> <3>CTRL-EVENT-STATE-CHANGE id=0 state=6 BSSID=00:00:00:00:00:00 SSID=FirefoxNetwork
> <3>Associated with 22:af:05:7e:d4:0a
> <3>CTRL-EVENT-CONNECTED - Connection to 22:af:05:7e:d4:0a completed (auth) [id=0 id_str=]
> <3>CTRL-EVENT-STATE-CHANGE id=0 state=9 BSSID=22:af:05:7e:d4:0a SSID=FirefoxNetwork
> <3>Unknown event 10
> get_network 0 mode
> 1
> 

The BSSID still seems missing.

Comment 18

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi Alan

(In reply to Alan K [:ack] from comment #14)
> https://github.com/mozilla/gecko-dev/blob/
> 987e99e6f8ac28f7510234f48813a4b596c9857e/dom/wifi/WifiCommand.jsm#L352
> 
> We don't currently allow other values for AP_SCAN, which might be necessary
> for Ad-hoc mode. I'm able to set the BSSID with wpa_cli, but wpa_supplicant
> ignores it.

You mentioned that you were able to connect the Flame to an Ad-hoc network using wpa_cli. I've been trying to do this, but without much success so far. Could you provide a listing of wpa_cli commands that works for you?

Comment 19

[Thomas Zimmermann [:tzimmermann] [:tdz]]

What I currently do is

  - scan for networks
  - add_network
  - set 'ap_scan 2'
  - set network mode
  - set network frequency
  - set network bssid
  - enable network

The logcat is shown below. There's nothing happening after ENABLE_NETWORK. Any idea is welcome.

D/wpa_supplicant(  905): RX ctrl_iface - hexdump(len=4): 50 49 4e 47
D/wpa_supplicant(  905): wlan0: Control interface command 'PING'
D/wpa_supplicant(  905): RX ctrl_iface - hexdump(len=4): 50 49 4e 47
D/wpa_supplicant(  905): wlan0: Control interface command 'PING'
D/wpa_supplicant(  905): wlan0: No enabled networks (1 disabled networks)
D/wpa_supplicant(  905): wlan0: No enabled networks - do not scan
D/wpa_supplicant(  905): wlan0: State: INACTIVE -> INACTIVE
D/wpa_supplicant(  905): wlan0: P2P: Station mode scan operation not pending anymore (sta_scan_pending=0 p2p_cb_on_scan_complete=0)
D/wpa_supplicant(  905): RX ctrl_iface - hexdump(len=16): 45 4e 41 42 4c 45 5f 4e 45 54 57 4f 52 4b 20 30
D/wpa_supplicant(  905): wlan0: Control interface command 'ENABLE_NETWORK 0'
D/wpa_supplicant(  905): CTRL_IFACE: ENABLE_NETWORK id=0
D/wpa_supplicant(  905): wlan0: Setting scan request: 0 sec 0 usec
D/wpa_supplicant(  905): RX ctrl_iface - hexdump(len=4): 50 49 4e 47
D/wpa_supplicant(  905): wlan0: Control interface command 'PING'
D/wpa_supplicant(  905): RX ctrl_iface - hexdump(len=11): 53 41 56 45 5f 43 4f 4e 46 49 47

Comment 20

[Alan K [:ack]]

I wasn't able to get ad-hoc working on the Flame at all. Everything I've got working so far has been on nexus4.

I'm not sure what the problem is on the Flame. I'll open a bug for this later today (unless you beat me to it).

Comment 21

[Alan K [:ack]]

@tzimmermann: After applying the AP_SCAN fix, I'm able to get my flame to into IBSS mode.

Comment 22

[Alan K [:ack]]

I'm encountering issues with wpa_supplicant on the flame. I can get it into ad-hoc mode once, but after that it fails. Will post logs in a bit.

Comment 23

[Alan K [:ack]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1065081

Comment 24

[Alan K [:ack]]

Comment on attachment 8479020 [details] [diff] [review]
[02] WIP: Set AP_SCAN before adding network

Review of attachment 8479020 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wifi/WifiWorker.js
@@ +1288,5 @@
> +    let ap_scan = (config.mode == MODE_IBSS) ? 2 : 1;
> +
> +    wifiCommand.setScanResultHandling(ap_scan, function(ok) {
> +      if (!ok)
> +        callback(false);

Should there be an early return here?

Comment 25

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: [01] Bug 928362: Support ad-hoc mode for Wifi (v4)

Changes since v3:

  - rebased onto latest trunk

Comment 26

[Thomas Zimmermann [:tzimmermann] [:tdz]]

https://hg.mozilla.org/integration/b2g-inbound/rev/eea1504453bf

https://treeherder.mozilla.org/ui/#/jobs?repo=b2g-inbound&revision=eea1504453bf

Comment 27

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/eea1504453bf

Comment 28

[Florian Bender]

Can you please clarify when this landed by fixing the "Target Milestone"? Thanks!

Comment 29

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I guess it's this one.