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)
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
Reporter | ||
Comment 1•11 years ago
|
||
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?
Reporter | ||
Updated•11 years ago
|
Keywords: regression
Updated•11 years ago
|
Component: General → Wifi
Comment 3•11 years ago
|
||
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)
Comment 4•11 years ago
|
||
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.
Assignee | ||
Comment 5•11 years ago
|
||
(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)
Reporter | ||
Comment 7•11 years ago
|
||
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)
Reporter | ||
Comment 8•11 years ago
|
||
I executed the tests in Spain, so hotspots follow European regulations
Reporter | ||
Comment 9•11 years ago
|
||
This is the log (using latest unagi 1.1 build), just starting the phone with both hotspots enabled: phone cannot get connected
Reporter | ||
Comment 10•11 years ago
|
||
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
Assignee | ||
Comment 12•11 years ago
|
||
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.
Reporter | ||
Comment 13•11 years ago
|
||
Disabling WiFi in any of the hotspots, phone is able to connect to the other one (I tested both cases)
Comment 14•11 years ago
|
||
(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)
Assignee | ||
Comment 16•11 years ago
|
||
(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)
Comment 17•11 years ago
|
||
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
Comment 18•11 years ago
|
||
seem like things are working. let me know if we still need to contact our partner
Flags: needinfo?(jcheng)
Comment 19•11 years ago
|
||
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.
Description
•