Closed Bug 921441 Opened 11 years ago Closed 11 years ago

Cannot connect to WiFi when having two hotspots with same SSID and same configuration

Categories

(Firefox OS Graveyard :: Wifi, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:-)

RESOLVED WORKSFORME
blocking-b2g -

People

(Reporter: sonmarce, Assigned: chucklee)

Details

(Keywords: regression)

Attachments

(2 files)

Tested in an unagi with latest version 1.1

Steps to reproduce:
1. Have two WiFi hotspots with same SSID and same configuration (different frequency)
2. Try to connect phone to WiFi from a place with enough coverage to connect both hotspots

Expected result: Phone gets connected to WiFi via one of the hotspots

Actual result: Phone tries to connect to WiFi several time, but it finally fails
If I disable radio in any of the hotspots, phone gets connected with no problem. It was working well in earlier commits of version 1.1, I do not know when it stopped working. It happens the same in master. Repeating the test with laptops and android devices it works well. For home users with coverage problems it is a common solution to have more than one hotspot.
blocking-b2g: --- → leo?
Keywords: regression
Ken,

Please check as this is a wifi issue.
Flags: needinfo?(kchang)
Component: General → Wifi
Because user may use different SSID for different WIFI access point(Wifi route, or Hotspot of device) at home, user can choice which wifi access point he want to connect.
But it seems to be the problem for enterprise. Company prefers to enable a roaming network for WIFI.
Flags: needinfo?(kchang) → needinfo?(chulee)
I just setup two APs (one is buri, the other one is Galaxy S2) with the same SSID and security type (security type: OPEN). The unagi with MC build can connect to one of the APs successfully.
(In reply to Ken Chang from comment #3)
> Because user may use different SSID for different WIFI access point(Wifi
> route, or Hotspot of device) at home, user can choice which wifi access
> point he want to connect.
> But it seems to be the problem for enterprise. Company prefers to enable a
> roaming network for WIFI.

Gecko doesn't have control over the connection process, it only request wpa_supplicant to connect and wait for results.
So it's unlikely that any modification on gecko will result in such issue.

I think we have to check the log, with Wifi Debug Log enabled(Settings->Device information->More information->Developer->Wi-Fi output in adb)

Also we need more detail on the AP settings, like
- Channel of each AP.
- Signal strength of each AP at test location.
- Does the APs support AP-controlled roaming.
Flags: needinfo?(chulee)
Please provide log for us. Thanks.
Flags: needinfo?(marce)
These are the WiFi hotspots I am using:
* Comtrend C5813 (FTTH router) - being used to get Internet access
* Netgear DGN1000 (ADSL2+ router) - just being used as hotspot connected by cable to the other hotspot

And this it he configuration:
* Same SSID and password in both hotspots
* Same encryption: WPA2-PSK & AES
* Different radio channel:
  * Comtrend C5813: band 2.4 GHz, channel 3 (2422 MHz)
  * Netgear DGN1000: band 2.4 GHz, channel 8 (2447 MHz)

And mobile phone is in coverage of both both of them (good & similar power level, in the range of -55 to -45 dBm): this configuration is working well with android devices, Microsoft Windows laptops and Mac OS laptops
Flags: needinfo?(marce)
I executed the tests in Spain, so hotspots follow European regulations
This is the log (using latest unagi 1.1 build), just starting the phone with both hotspots enabled: phone cannot get connected
This is the log (using latest unagi 1.1 build), starting with phone connected to WiFi disabling one of the hotspots, then reenabling all hotspots and trying to reconnect: phone cannot get connected even when it was already connected
Assign to Chuck.
Assignee: nobody → chulee
Error log:
D/wpa_supplicant(  360): wlan0: Request association: reassociate: 1  selected: 00:26:f2:45:3d:3c  bssid: 00:00:00:00:00:00  pending: 00:00:00:00:00:00  wpa_state: SCANNING
I/wpa_supplicant(  360): wlan0: Trying to associate with SSID 'arraia'
...
D/wpa_supplicant(  360): WPA: PTK derivation - A1=f4:6d:e2:c9:92:34 A2=00:1a:2b:ae:91:4f
W/wpa_supplicant(  360): wlan0: WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp (src=00:1a:2b:ae:91:4f)
D/wpa_supplicant(  360): wpa_driver_nl80211_disconnect(addr=00:1a:2b:ae:91:4f reason_code=17)
I/wpa_supplicant(  360): wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
D/wpa_supplicant(  360): Added BSSID 00:1a:2b:ae:91:4f into blacklist
...
D/wpa_supplicant(  360): wlan0: Request association: reassociate: 0  selected: 00:26:f2:45:3d:3c  bssid: 00:00:00:00:00:00  pending: 00:00:00:00:00:00  wpa_state: DISCONNECTED
I/wpa_supplicant(  360): wlan0: Trying to associate with SSID 'arraia'
...
I/Gecko   (  109): -*- WifiWorker component: Event coming in: Associated with 00:1a:2b:ae:91:4f
I/Gecko   (  109): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=7 BSSID=00:00:00:00:00:00
I/Gecko   (  109): -*- WifiWorker component: State change: ASSOCIATED -> FOUR_WAY_HANDSHAKE
I/Gecko   (  109): -*- WifiWorker component: Event coming in: WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp (src=00:1a:2b:ae:91:4f)
I/Gecko   (  109): -*- WifiWorker component: Event coming in: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
I/Gecko   (  109): -*- WifiWorker component: Event coming in: CTRL-EVENT-DISCONNECTED bssid=00:1a:2b:ae:91:4f reason=17
I/Gecko   (  109): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=0 BSSID=00:00:00:00:00:00
I/Gecko   (  109): -*- WifiWorker component: State change: FOUR_WAY_HANDSHAKE -> DISCONNECTED

The log shows two problems:

1. The AP with MAC 00:1a:2b:ae:91:4f might be malfunction.
   It's rare condition to cause the four-way-handshake failure on phase 3, but I can't do further analyze based on the logs.
   => Please try to connect this AP with another AP disabled first, to check if it can be connected.

2. AP black list function in wpa_supplicant/driver seems not work, otherwise the device should try to connect to another AP(00:26:f2:45:3d:3c) instead of staying on the first one.
   => I will try to create a test environment for STR, and I think this issue needs support from our partners.
Disabling WiFi in any of the hotspots, phone is able to connect to the other one (I tested both cases)
(In reply to Chuck Lee [:chucklee] from comment #12)
> 2. AP black list function in wpa_supplicant/driver seems not work, otherwise
> the device should try to connect to another AP(00:26:f2:45:3d:3c) instead of
> staying on the first one.
>    => I will try to create a test environment for STR, and I think this
> issue needs support from our partners.
Joe, can partner help this?
Flags: needinfo?(jcheng)
Chuck, what kind of qawanted help do you need?
Flags: needinfo?(chulee)
(In reply to ckreinbring from comment #15)
> Chuck, what kind of qawanted help do you need?

We can't reproduce this bug using our equipment, so I would like QA try if this bug can be reproduced with different equipments, based on environment described in Comment 7(Except for the AP model, I don't think we have those).
Flags: needinfo?(chulee)
We were also unable to repro on our equipment, although we attempted the repro with Buri 1.2 mozilla RIL.

We tested two scenarios:
1. Two wireless routers setup with the same SSID on different channels
2. Two wireless routers setup with the same SSID on the same channel

Test-1
Router #1 SSID - MOZ-WPA
Set to WPA-2 Personal TKIP&AES Channel 3-2.422Ghz

Router #2 SSID - MOZ-WPA
Set to WPA-2 Personal TKIP&AES Channel 8-2447Ghz

Test-2
Router #1 SSID - MOZ-WPA
Set to WPA-2 Personal TKIP&AES Channel 8-2447Ghz

Router #2 SSID - MOZ-WPA
Set to WPA-2 Personal TKIP&AES Channel 8-2447Ghz

In both tests, the device connected with no problems.

Build ID: 20131016004005
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/75b0b968f3ed
Gaia: 5ef3535021286ccab7af639897feaaf5955720a0
Platform Version: 26.0a2
Keywords: qawanted
seem like things are working. let me know if we still need to contact our partner
Flags: needinfo?(jcheng)
Given comment #18, removing the nom and marking this resolved workforme
Status: NEW → RESOLVED
blocking-b2g: leo? → -
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: