但是命令发到wpa_supplicant后的流程网上提到的资料就非常少了,不过由于wpa_supplicant是一个标准的开源项目,已经被移植到很多平台上,它中间的过程我暂时还没有去细看。比较关心的是wpa_supplicant在接收到上层的命令后是怎么将命令发给DRIVER的,DRIVER在接收到命令后的解析的动作以及之后调用驱动功能函数的流程以及驱动对寄存器控制的细节。由于需要注意代码保密,之后不会提及具体使用了哪块WIFI芯片也不会提及此WIFI DRIVER是在什么平台什么产品。
先贴一张wpa_supplicant的标准结构框图:
重点关注框图的下半部分,即wpa_supplicant是如何与DRIVER进行联系的。整个过程暂以AP发出SCAN命令为主线。由于现在大部分WIFI DRIVER都支持wext,所以就假设我们的设备走的是wext这条线,其实用ndis也一样,流程感觉差不多。
首先要说的是,在Driver.h文件中有个结构体wpa_driver_ops:
/**
* struct wpa_driver_ops - Driver interface API definition
*
* This structure defines the API that each driver interface needs to implement
* for core wpa_supplicant code. All driver specific functionality is captured
* in this wrapper.
*/
struct wpa_driver_ops
这个结构体在Driver.c中被声明为:
#ifdef CONFIG_DRIVER_WEXT
extern struct wpa_driver_ops wpa_driver_wext_ops; /* driver_wext.c */
然后在driver_wext.c填写了结构体的成员,
const struct wpa_driver_ops wpa_driver_wext_ops = {
.name = "wext",
.desc = "Linux wireless extensions (generic)",
.get_bssid = wpa_driver_wext_get_bssid,
.get_ssid = wpa_driver_wext_get_ssid,
.set_wpa = wpa_driver_wext_set_wpa,
.set_key = wpa_driver_wext_set_key,
.set_countermeasures = wpa_driver_wext_set_countermeasures,
.set_drop_unencrypted = wpa_driver_wext_set_drop_unencrypted,
.scan = wpa_driver_wext_scan,
.combo_scan = wpa_driver_wext_combo_scan,
.get_scan_results2 = wpa_driver_wext_get_scan_results,
.deauthenticate = wpa_driver_wext_deauthenticate,
.disassociate = wpa_driver_wext_disassociate,
.set_mode = wpa_driver_wext_set_mode,
.associate = wpa_driver_wext_associate,
.set_auth_alg = wpa_driver_wext_set_auth_alg,
.init = wpa_driver_wext_init,
.deinit = wpa_driver_wext_deinit,
.add_pmkid = wpa_driver_wext_add_pmkid,
.remove_pmkid = wpa_driver_wext_remove_pmkid,
.flush_pmkid = wpa_driver_wext_flush_pmkid,
.get_capa = wpa_driver_wext_get_capa,
.set_operstate = wpa_driver_wext_set_operstate,
#ifdef ANDROID
.driver_cmd = wpa_driver_priv_driver_cmd,
#endif
};
这些成员其实都是驱动和wpa_supplicant的接口,以SCAN为例:
int wpa_driver_wext_scan(void *priv, const u8 *ssid, size_t ssid_len)
中的LINE1174:if (ioctl(drv->ioctl_sock, SIOCSIWSCAN, &iwr) < 0)从这里可以看出wpa_cupplicant是通过IOCTL来调用SOCKET与DRIVER进行通信的,并给DRIVER下达SIOCSIWSCAN这个命令。
这样,一个命令从AP到FRAMEWORK到C++本地库再到wpa_supplicant适配层,再由wpa_supplicant下CMD给DRIVER的路线就打通了,写起来虽然不多但也是一点小成果。
时间过得很快,毕业已经三周了,后悔当初在实验室没有去学习关于WIFI的知识,现在只好从头看起。好在公司环境比较轻松,可以有时间抓抓细节,后面就要开始将DRIVER部分的结构和流程理理清楚了。
由于在这个项目中,WIFI模块是采用SDIO总线来控制的,所以先记录下CLIENT DRIVER的SDIO部分的结构,这部分的SDIO分为三层:SdioDrv、SdioAdapter、SdioBusDrv。其中SdioBusDrv是Client Driver中SDIO与WIFI模块的接口,SdioAdapter是SdioDrv和SdioBusDrv之间的适配层,SdioDrv是Client Driver中SDIO与LINUX KERNEL中的MMC SDIO的接口。这三部分只需要关注一下SdioDrv就可以了,另外两层都只是对它的封装罢了。
在SdioDrv中提供了这几个功能:
(1)static struct sdio_driver tiwlan_sdio_drv = {
.probe = tiwlan_sdio_probe,
.remove = tiwlan_sdio_remove,
.name = "sdio_tiwlan",
.id_table = tiwl12xx_devices,
};
(2)int sdioDrv_EnableFunction(unsigned int uFunc)
(3)int sdioDrv_EnableInterrupt(unsigned int uFunc)
(4)SDIO的读写,实际是调用了MMC\Core中的 static int mmc_io_rw_direct_host()功能。
SDIO功能部分简单了解下就可以,一般HOST部分芯片厂商都会做好。我的主要任务还是WIFI模块。
首先从WIFI模块的入口函数wlanDrvIf_ModuleInit()看起,这里调用了wlanDrvIf_Create()。
代码主体部分:
static int wlanDrvIf_Create (void)
{
TWlanDrvIfObj *drv; //这个结构体为代表设备,包含LINUX网络设备结构体net_device
pDrvStaticHandle = drv; /* save for module destroy */
drv->pWorkQueue = create_singlethread_workqueue (TIWLAN_DRV_NAME);//创建了工作队列
/* Setup driver network interface. */
rc = wlanDrvIf_SetupNetif (drv); //这个函数超级重要,后面详细的看
drv->wl_sock = netlink_kernel_create( NETLINK_USERSOCK, 0, NULL, NULL, THIS_MODULE );
// 创建了接受wpa_supplicant的SOCKET接口
/* Create all driver modules and link their handles */
rc = drvMain_Create (drv,
&drv->tCommon.hDrvMain,
&drv->tCommon.hCmdHndlr,
&drv->tCommon.hContext,
&drv->tCommon.hTxDataQ,
&drv->tCommon.hTxMgmtQ,
&drv->tCommon.hTxCtrl,
&drv->tCommon.hTWD,
&drv->tCommon.hEvHandler,
&drv->tCommon.hCmdDispatch,
&drv->tCommon.hReport,
&drv->tCommon.hPwrState);
/*
* Initialize interrupts (or polling mode for debug):
*/
/* Normal mode: Interrupts (the default mode) */
rc = hPlatform_initInterrupt (drv, (void*)wlanDrvIf_HandleInterrupt);
return 0;
}
在调用完wlanDrvIf_Create()这个函数后,实际上WIFI模块的初始化就结束了,下面分析如何初始化的。先看wlanDrvIf_SetupNetif (drv)这个函数的主体,
static int wlanDrvIf_SetupNetif (TWlanDrvIfObj *drv)
{
struct net_device *dev;
int res;
/* Allocate network interface structure for the driver */
dev = alloc_etherdev (0);//申请LINUX网络设备
if (dev == NULL)
/* Setup the network interface */
ether_setup (dev);//建立网络接口 ,这两个都是LINUX网络设备驱动的标准函数
dev->netdev_ops = &wlan_netdev_ops;
/* Initialize Wireless Extensions interface (WEXT) */
wlanDrvWext_Init (dev);
res = register_netdev (dev);
/* Setup power-management callbacks */
hPlatform_SetupPm(wlanDrvIf_Suspend, wlanDrvIf_Resume, pDrvStaticHandle);
}
注意,在这里初始化了wlanDrvWext_Inti(dev),这就说明wpa_supplicant与Driver直接的联系是走的WEXT这条路。也就是说event的接收,处理也应该是在WEXT部分来做的,确定这个,剩下的工作量顿减三分之一,哈哈哈。后面还注册了网络设备dev。而在wlan_netdev_ops中定义的功能如下:
static const struct net_device_ops wlan_netdev_ops = {};
功能一看名字就知道了,不说了,这几个对应的都是LINUX网络设备驱动都有的命令字,详见《LINUX设备驱动开发详解》第十六章。
在这之后,又调用了rc =drvMain_CreateI。
在这个函数里完成了相关模块的初始化工作。具体不说了。接下来就是等待Android上层发送来的事件了。
WIFI已经可以工作了,大部分android wifisetting里要求的功能也都实现了,不过还有两个问题在这里记录一下:
1. Softap无法使用
2. 通过WPS联网的时候有一定几率会失败。
对于softap,当在setting中选下WIFI TETHERING时,softapcontroller就会给DRIVER发送私有命令,不过在发送私有命令前会先通过IOCTL发送SIOCGIWPRIV这个命令字给DRIVER。这个命令的作用是获得当前DRIVER所支持的私有命令。(因为SOFTAP并不是standard cmd, 所以如果要支持的话必须放在私有命令中)
而DRIVER是否支持私有命令,或者说支持哪些私有命令就要看DRIVER中关于结构体iw_handler_def的赋值:
const struct iw_handler_def wl_iw_handler_def =
{
.num_standard = ARRAYSIZE(wl_iw_handler),
.standard = (iw_handler *) wl_iw_handler,
.num_private = ARRAYSIZE(wl_iw_priv_handler),
.num_private_args = ARRAY_SIZE(wl_iw_priv_args),
.private = (iw_handler *)wl_iw_priv_handler,
.private_args = (void *) wl_iw_priv_args,
};
而我这边由于不知到手上的模块支持哪些private cmd。所以这块自己没办法加,只有联系供应厂商提供支援,现在暂时空下,等支援OK了再该过来。