Closed Bug 928362 Opened 6 years ago Closed 5 years ago

Implementation of 802.11 (Wi-Fi) ad hoc feature

Categories

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

defect

Tracking

(tracking-b2g:backlog, relnote-b2g ?)

RESOLVED FIXED
2.1 S7 (24Oct)
tracking-b2g backlog
Tracking Status
relnote-b2g --- ?

People

(Reporter: firefoxos, Assigned: tzimmermann)

References

Details

(Keywords: access, dev-doc-needed)

Attachments

(3 files, 4 obsolete files)

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/
Severity: normal → enhancement
Keywords: access
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*
See Also: → 811635
See Also: → 890261
See Also: → 821539
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.
Severity: enhancement → critical
Priority: -- → P2
blocking-b2g: --- → 1.3?
Target Milestone: --- → DeveloperPhone
blocking-b2g: 1.3? → ---
1.3 is FC already.
blocking-b2g: --- → backlog
Duplicate of this bug: 890261
Assignee: nobody → tzimmermann
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8425481 - Flags: review?(vchang)
With this patch, the Settings app adds the label 'Ad-hoc mode' to detected ad-hoc networks.
This shows the effect of the Gaia change. You can see that 'FirefoxNetwork' is labeled with 'Ad-hoc mode'.
Duplicate of this bug: 932372
No longer blocks: 945047
Attachment #8425485 - Attachment description: Mke settings app indicate ad-hoc networks → Make settings app indicate ad-hoc networks
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 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.
Attachment #8425481 - Flags: review?(vchang)
(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.
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'
Attachment #8425481 - Attachment is obsolete: true
Attachment #8472852 - Flags: review?(vchang)
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 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.
Attachment #8472852 - Flags: review?(vchang)
Attachment #8472852 - Flags: review?(mrbkap)
Attachment #8472852 - Flags: review+
Attachment #8472852 - Flags: review?(mrbkap) → review+
Changes since v2:

  - fixed comment
Attachment #8472852 - Attachment is obsolete: true
Attachment #8479014 - Flags: review+
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.
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?
Flags: needinfo?(akligman)
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
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).
Flags: needinfo?(akligman)
@tzimmermann: After applying the AP_SCAN fix, I'm able to get my flame to into IBSS mode.
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 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?
Blocks: 1066709
Changes since v3:

  - rebased onto latest trunk
Attachment #8479014 - Attachment is obsolete: true
Attachment #8479020 - Attachment is obsolete: true
Attachment #8507844 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/eea1504453bf
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
relnote-b2g: --- → ?
Can you please clarify when this landed by fixing the "Target Milestone"? Thanks!
Flags: needinfo?(tzimmermann)
I guess it's this one.
Flags: needinfo?(tzimmermann)
Target Milestone: DeveloperPhone → 2.1 S7 (24Oct)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.