Closed
Bug 972794
Opened 11 years ago
Closed 11 years ago
[Tarako]Connect wpa supplicant consume 5 seconds
Categories
(Firefox OS Graveyard :: Wifi, defect)
Firefox OS Graveyard
Wifi
Tracking
(blocking-b2g:1.3T+, b2g-v1.3T fixed)
People
(Reporter: xinhe.yan, Assigned: vchang)
Details
Attachments
(1 file)
|
1.24 KB,
patch
|
chucklee
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Android connect wpa_supplicant 5 times and nap is 1 second.
b2g connect wpa_supplicant 3 times and nap is 5 second.
I checked broadcom and our trout wifi chip.They both need connect wpa twice.
I prefer follow android.
WifiWorker.js
function connectCallback(ok) {
if (ok === 0) {
// Tell the event worker to start waiting for events.
retryTimer = null;
connectTries = 0;
didConnectSupplicant(function(){});
return;
}
if (connectTries++ < 3) {
// Try again in 5 seconds.
if (!retryTimer)
retryTimer = Cc["@mozilla.org/timer;1"].createInstance(Ci.nsITimer);
retryTimer.initWithCallback(function(timer) {
wifiCommand.connectToSupplicant(connectCallback);
}, 5000, Ci.nsITimer.TYPE_ONE_SHOT);
return;
}
retryTimer = null;
connectTries = 0;
notify("supplicantlost", { success: false });
}
WifiMonitor.java
private boolean connectToSupplicant() {
int connectTries = 0;
while (true) {
if (WifiNative.connectToSupplicant()) {
return true;
}
if (connectTries++ < 5) {
nap(1);
} else {
break;
}
}
return false;
}
| Assignee | ||
Comment 2•11 years ago
|
||
Hi Xinhe, it definitely fine for me to modify that retry interval. But I am wonding why do we need to connect wpa_supplicatn twice in most of time ?
(In reply to Vincent Chang[:vchang] from comment #2)
> Hi Xinhe, it definitely fine for me to modify that retry interval. But I am
> wonding why do we need to connect wpa_supplicatn twice in most of time ?
start_supplican will return after call property_set("ctl.start", daemon_cmd);.
But between start_supplicant return and wpa_supplicant finish initialize, the time is uncertain.
Task scheduling or other factor may affect this time.
This can be verify by log.
Wpa not init before first wifi_connect_to_supplicant.
02-17 06:45:51.810 E/WifiHW ( 81): xinhe enter wifi_connect_to_supplicant
02-17 06:45:51.810 E/WifiHW ( 81): Unable to open connection to supplicant on "wlan0": No such file or directory
02-17 06:45:51.810 I/Gecko ( 81): -*- WifiWorker component: xinhe wpa connectCallback result-1
02-17 06:45:51.880 D/wpa_supplicant( 494): wpa_supplicant v0.8.x
I also test on our tiger chip(Dual CPU 1.2GHz Cortex-A5\RAM 512M ). Connect wpa_supplicant will success after start wpa.
This bug will be amplify on cheap phone.
02-17 06:45:51.800 I/Gecko ( 81): xinhe WifiUtils command start_supplicant
02-17 06:45:51.800 E/WifiHW ( 81): Leo ensure_config_file_exists config_file=/data/misc/wifi/wpa_supplicant.conf
02-17 06:45:51.800 E/WifiHW ( 81): daemon_cmd=wpa_supplicant:-iwlan0 -c/data/misc/wifi/wpa_supplicant.conf
02-17 06:45:51.800 E/WifiHW ( 81): xinhe wifi_start_supplicant return 0
02-17 06:45:51.800 I/Gecko ( 81): -*- WifiWorker component: xinhe wpa started ,then send enableInterface
02-17 06:45:51.800 I/Gecko ( 81): xinhe WifiUtils command ifc_enable
02-17 06:45:51.800 I/Gecko ( 81): -*- WifiWorker component: xinhe detected SDK version then connectToSupplicant15
02-17 06:45:51.810 I/Gecko ( 81): xinhe WifiUtils command connect_to_supplicant
02-17 06:45:51.810 E/WifiHW ( 81): xinhe enter wifi_connect_to_supplicant
02-17 06:45:51.810 E/WifiHW ( 81): Unable to open connection to supplicant on "wlan0": No such file or directory
02-17 06:45:51.810 I/Gecko ( 81): -*- WifiWorker component: xinhe wpa connectCallback result-1
02-17 06:45:51.880 D/wpa_supplicant( 494): wpa_supplicant v0.8.x
02-17 06:45:51.880 D/wpa_supplicant( 494): random: Trying to read entropy from /dev/random
02-17 06:45:51.880 D/wpa_supplicant( 494): Initializing interface 'wlan0' conf '/data/misc/wifi/wpa_supplicant.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A'
02-17 06:45:51.880 D/wpa_supplicant( 494): Configuration file '/data/misc/wifi/wpa_supplicant.conf' -> '/data/misc/wifi/wpa_supplicant.conf'
02-17 06:45:51.880 D/wpa_supplicant( 494): Reading configuration file '/data/misc/wifi/wpa_supplicant.conf'
02-17 06:45:51.880 D/wpa_supplicant( 494): ctrl_interface='/data/system/wpa_supplicant'
02-17 06:45:51.880 D/wpa_supplicant( 494): update_config=1
02-17 06:45:51.880 D/wpa_supplicant( 494): Line: 5 - start of a new network block
02-17 06:45:51.890 D/wpa_supplicant( 494): key_mgmt: 0x4
02-17 06:45:51.890 D/wpa_supplicant( 494): priority=1 (0x1)
02-17 06:45:51.890 D/wpa_supplicant( 494): Line: 11 - start of a new network block
02-17 06:45:51.890 D/wpa_supplicant( 494): key_mgmt: 0x1
02-17 06:45:51.890 D/wpa_supplicant( 494): priority=2 (0x2)
02-17 06:45:51.890 D/wpa_supplicant( 494): Priority group 2
02-17 06:45:51.890 D/wpa_supplicant( 494): id=1 ssid='CMCC-AUTO'
02-17 06:45:51.890 D/wpa_supplicant( 494): Priority group 1
02-17 06:45:51.890 D/wpa_supplicant( 494): id=0 ssid='CMCC'
02-17 06:45:51.890 D/wpa_supplicant( 494): nl80211: interface wlan0 in phy phy1
02-17 06:45:52.810 I/Gecko ( 81): xinhe WifiUtils command connect_to_supplicant
02-17 06:45:52.810 E/WifiHW ( 81): xinhe enter wifi_connect_to_supplicant
02-17 06:45:52.820 I/Gecko ( 81): -*- WifiWorker component: xinhe wpa connectCallback result0
| Assignee | ||
Updated•11 years ago
|
Assignee: nobody → vchang
| Assignee | ||
Comment 4•11 years ago
|
||
Start wpa_supplicant command in wifi.c has checked the status of init.svc.wpa_supplicant after doing the property_set("ctl.start", daemon_cmd).
http://androidxref.com/4.0.4/xref/hardware/libhardware_legacy/wifi/wifi.c#522
So the status running doesn't means wpa_supplicant is ready for accept a connection ?
We don't need to modify the retry timer if we can guarantee this. Does it make sense to you ?
Flags: needinfo?(xinhe.yan)
(In reply to Vincent Chang[:vchang] from comment #4)
> Start wpa_supplicant command in wifi.c has checked the status of
> init.svc.wpa_supplicant after doing the property_set("ctl.start",
> daemon_cmd).
> http://androidxref.com/4.0.4/xref/hardware/libhardware_legacy/wifi/wifi.c#522
>
> So the status running doesn't means wpa_supplicant is ready for accept a
> connection ?
status running doesn't means wpa already init
02-25 04:50:34.580 E/WifiHW ( 82): daemon_cmd=wpa_supplicant:-iwlan0 -c/data/misc/wifi/wpa_supplicant.conf
02-25 04:50:34.580 E/WifiHW ( 82): wifi_start_supplicant_common start wpa_supplicant and wait for running
02-25 04:50:34.580 E/WifiHW ( 82): count is 199
02-25 04:50:34.580 E/WifiHW ( 82): get wpa status running
02-25 04:50:34.590 E/WifiHW ( 82): Unable to open connection to supplicant on "wlan0": No such file or directory
02-25 04:50:34.720 D/wpa_supplicant( 3519): wpa_supplicant v0.8.x
Unable to open connection to supplicant on "wlan0"
This log came from wifi_connect_to_supplicant. But system never get a chance to start wpa.
Hamachi use different wifi.c
wifi_start_supplicant_common wait wifi.wpa_supp_ready and return.
caf log:
07-09 22:23:31.219 E/WifiHW ( 136): enter wifi_start_supplicant_common
07-09 22:23:31.219 E/WifiHW ( 136): start wpa_supplicant
07-09 22:23:31.219 E/WifiHW ( 136): wpa status running
07-09 22:23:31.319 D/wpa_supplicant( 460): wpa_supplicant v2.0-devel-4.0.4.0.4.0.4
07-09 22:23:31.559 E/WifiHW ( 136): return 0 in wifi_start_supplicant_common
07-09 22:23:31.569 E/WifiHW ( 136): wifi_connect_to_supplicant
Flags: needinfo?(xinhe.yan)
Vincent, any update? It's been open for a while.
Flags: needinfo?(vchang)
| Assignee | ||
Comment 7•11 years ago
|
||
Per comment 4, I still think that it's better to optimize this in wpa_supplicant or wifi.c in libhardware_legacy. I'll post a patch soon.
Flags: needinfo?(vchang)
| Assignee | ||
Comment 8•11 years ago
|
||
Follow the Android to reconnect to wpa_supplicant.
Attachment #8387520 -
Flags: review?(chulee)
| Assignee | ||
Comment 9•11 years ago
|
||
Hi Xinhe, can you help to double check if this patch improve the wifi startup time ?
Flags: needinfo?(xinhe.yan)
| Reporter | ||
Comment 10•11 years ago
|
||
Thanks Vincent, this patch will decrease 4 seconds.
Flags: needinfo?(xinhe.yan)
Comment on attachment 8387520 [details] [diff] [review]
wifi.v1.0.patch
Review of attachment 8387520 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good, Thanks.
I think we can open a follow up bug to move all these constants to property, so partners can optimize them for different devices without changing gecko code.
Attachment #8387520 -
Flags: review?(chulee) → review+
| Assignee | ||
Comment 12•11 years ago
|
||
| Assignee | ||
Comment 13•11 years ago
|
||
Nominate for 1.3T because this fix is mainly for Tarako.
blocking-b2g: --- → 1.3T?
Comment 14•11 years ago
|
||
Hi Ying, please uplift the patch to v1.3T. Thanks!
blocking-b2g: 1.3T? → 1.3T+
Flags: needinfo?(ying.xu)
Comment 15•11 years ago
|
||
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 16•11 years ago
|
||
status-b2g-v1.3T:
--- → fixed
Flags: needinfo?(ying.xu)
You need to log in
before you can comment on or make changes to this bug.
Description
•