Modify wifi_load_driver behavior synchronize startHal with the initialization
of the wlan driver. This makes sure that on certain solutions, startHal will
does not fail due to no wlan0 net device not being found.
Bug:19888853
Change-Id: Ic6ec2211431c478e52eb516c40ec23c2e8945fbb
Signed-off-by: Maddest Chang <maddest.chang@mediatek.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Ensure wifi driver load failure status is compared with
valid string which has the failure/success information.
Change-Id: I3b619ad0c005fb793d127bd2a23b376ed961d0b7
wifi.c gets sys/stat.h inherited from
private/android_filesystem_config.h it should
not rely on this in the future. The intent is
to move fs_config function into libcutils and
thus deprecate any need for sys/stat.h in this
include file.
Bug: 19908228
Change-Id: Ie84477137dba47af385163decbb41b03e2aeaed4
specify timeout value in poll to check if the supplicant
connection is active, if not we should indicate
terminate command to framework to restart supplicant.
Change-Id: I8e602b9cb07a13c3f0b96813b2fc89f46457473e
Internal fabricated WPA_EVENT_TERMINATING events to restart
supplicant should be sent on primary interface.
Change-Id: I2d018e0707819614d9b092c6f3a812f04b5446ca
init.svc.*(hostapd, p2p_supplicant) properties are set when starting
STA or uAP via Wi-Fi HAL, after sending ctrl.start command to
property_service, thread called wifi_start_supplicant will yield cpu
for android init process to get scheduled, then init.svc.* status
is read to check if supplicant status is running
there is a chance that after scheld_yield returned, init is not
scheduled, serial value is not updated, __system_property_read got
the "stopped" status, then init is scheduled to update service status
after that back to this loop in Wi-Fi HAL, serial is updated, but
status is not reread, still used "stopped", then Wi-Fi HAL will
report supplicant start failed
as the following schedule sequence:
process A(WifiStateMachine) process B(init)
1. ctl.start
2. scheld_yield
3. __system_proerty_read
/*serial1, value1*/
4. __system_property_update
/*serial2, value2*/
5. serial1 != serial2
6. value1 == "stopped"
So after sched_yield, first check if serial is updated, then read
service status
Change-Id: I5181e0d4504c525832c033b9a35bd58ec63e1de8
Signed-off-by: jiaguo <jiaguo@marvell.com>
This helps to preapre for future updates from external sources.
Bug: 9298955
Change-Id: I4c63ad5fc1ea3564aab38cfce955de19bad75c0c
(cherry picked from commit 759cc323cb586192d591a815b0fb9d839536fcd6)
We saw a case of config file being corrupted. Add a mechanism to
recover from this when wifi is toggled off and on.
Bug: 8569820
Change-Id: If2baceb065838d2adb5cde61772d25a05455fc90
Wrong property was used to check if wpa_supplicant was running.
Fix this
Change-Id: I6a5bd7a3acae84f5ba4bba317d04191e0e59b2e7
Author: Jonathan DE CESCO <jonathan.de.cesco@intel.com>
Signed-off-by: Jonathan DE CESCO <jonathan.de.cesco@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 66748
lihardware_legacy was ALWAYS re-writing the
wpa_supplicant.conf file's "ctrl_interface" entry to the
value specified as the property wifi.interface, whose value
was typically "wlan0". This was designed to allow the
wpa_supplicant service to be started with a "socket"
directive in its service description in an init.rc file.
Under these circumstances, the socket name is exchanged
between wpa_supplicant and its WifiService client through an
environment variable whose name is derived from
wifi.interface and a standard prefix.
However, since the "ctrl_interface" entry was always
re-written in this way, it broke the ability to use
"ctrl_interface" in its standard usage as a directory where
the (unix-domain) socket will be exchanged.
This change restores the ability to use the standard
directory-form ctrl_interface usage by limiting the
re-writing of the ctrl_interface entry to cases where it
does not look like an absolute path or the "DIR=" form of
directory.
Change-Id: I96c8656d144c1ea41e25ab0eb0807f7b49193b49
Signed-off-by: Paul Drews <paul.drews@intel.com>
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Some system calls can be interrupted. wifi.c in particular was getting
into error conditions during bugreport because it doesn't handle EINTR
at all.
Change-Id: I7bec432a0b3dca7dcc5c03c5e9f5e9ed73fa3c4b
Right now, everything goes over the primary interface socket connection.
Add support for a seperate connection over the p2p interface.
Change-Id: I09118f88cfaa201b2d62d27add410cfd441d4454
Create a local pipe to track when socket connection times out
and send a terminate on the monitor thread
Bug: 5337272
Change-Id: I80ed3f8450b4d54d1b9e2bbc3cc84f10d0ae7a04
We stop supplicant by sending a "terminate" control command. init then
updates the system property init.svc.wpa_supplicant when the supplicant has stopped. The
framework gets notified of a successful supplicant stop through a supplicant event.
It can happen that the framework has been notified of a supplicant stop, but the init
process has not set the system property and thus when the framework tries to connect
to the supplicant again, it can immediately return saying the supplicant is already running.
Avoid this race, by ensuring the call from framework to close supplicant connection polls
for the update by init process that the system property indicates supplicant has stopped.
Bug: 5166494
Change-Id: Ie74a8cf39fa56ae557ea6bbbcba7865301620c42
