State of the OpenMoko wlan driver
Jason
openmoko at lakedaemon.net
Thu Sep 18 13:45:14 CEST 2008
Andy Green wrote:
[snip]
> | c) Does the driver support monitor mode with radiotap header or is there
> | another way to get the signal strength of other wlan adhoc stations in
> | range ?
>
> AIUI there is no monitor mode support, and that's down to the closed
> firmware. There has been no update of AR6001 firmware since before
> production and Atheros keep the firmware update utility private, so I
> would not hold your breath.
>
I was digging into this because it irked me [1], and saw a glimmer or
two of hope. First, I found this:
###################################
$ cd drivers/net/wireless/ar6k/
$ grep -rn HTC_RAW_INTERFACE *
ar6k_main.c:276:#ifdef HTC_RAW_INTERFACE
ar6k_main.c:297:#endif /* HTC_RAW_INTERFACE */
ar6k_main.c:915:#ifdef HTC_RAW_INTERFACE
ar6k_main.c:918:#endif /* HTC_RAW_INTERFACE */
ar6k_main.c:1020:#ifdef HTC_RAW_INTERFACE
ar6k_main.c:1069:#endif /* HTC_RAW_INTERFACE */
ar6k_main.c:1962:#ifdef HTC_RAW_INTERFACE
ar6k_main.c:2320:#endif /* HTC_RAW_INTERFACE */
include/athdrv.h:325:#ifdef HTC_RAW_INTERFACE
include/athdrv.h:360:#endif /* HTC_RAW_INTERFACE */
###################################
I removed some white space to clarify the above. So what is this? I'm
not sure, but enabling it defines some extended ioctls (XIOCTL) in
include/athdrv.h, particularly:
###################################
#define AR6000_XIOCTL_HTC_RAW_OPEN 13
#define AR6000_XIOCTL_HTC_RAW_CLOSE 14
#define AR6000_XIOCTL_HTC_RAW_READ 15
#define AR6000_XIOCTL_HTC_RAW_WRITE 16
###################################
and some functions in ar6k_main.c:
##########################################
#ifdef HTC_RAW_INTERFACE
static void ar6k_htc_raw_read_cb(HTC_TARGET * htcTarget,
HTC_ENDPOINT_ID endPointId,
HTC_EVENT_ID evId,
HTC_EVENT_INFO * evInfo, void *arg);
static void ar6k_htc_raw_unread_cb(HTC_TARGET * htcTarget,
HTC_ENDPOINT_ID endPointId,
HTC_EVENT_ID evId,
HTC_EVENT_INFO * evInfo, void *arg);
static void ar6k_htc_raw_write_cb(HTC_TARGET * htcTarget,
HTC_ENDPOINT_ID endPointId,
HTC_EVENT_ID evId,
HTC_EVENT_INFO * evInfo, void *arg);
static int ar6k_htc_raw_open(HTC_TARGET * htcTarget);
static int ar6k_htc_raw_close(HTC_TARGET * htcTarget);
static ssize_t ar6k_htc_raw_read(HTC_TARGET * htcTarget,
HTC_ENDPOINT_ID endPointId,
char __user * buffer, size_t count);
static ssize_t ar6k_htc_raw_write(HTC_TARGET * htcTarget,
HTC_ENDPOINT_ID endPointId,
char __user * buffer, size_t count);
#endif /* HTC_RAW_INTERFACE */
############################################
Unfortunately, A comment in ar6k_main.c:903 says this:
############################################
/* This would basically hold all the private ioctls that are not related
to WLAN operation */
static int ar6k_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
############################################
Which means those AR6000_XIOCTL_HTC_RAW_* probably don't do what we want.
Moving on... So, in my digging, I remembered seeing some *Skb*
functions that were commented out:
#######################################
$ grep -rn Skb *
include/htc.h:90: HTCSkbReceive(HTC_TARGET * target,
HTC_ENDPOINT_ID endPointId,
include/htc.h:101: HTCSkbSend(HTC_TARGET * target, HTC_ENDPOINT_ID
endPointId,
#######################################
And here it is in context:
###################################################
int
HTCBufferReceive(HTC_TARGET * target, HTC_ENDPOINT_ID endPointId,
u8 * buffer, u32 length, void *cookie);
/* target - IN, endPointId - IN, buffer - IN, length - IN, cookie - IN */
#if 0
int
HTCSkbReceive(HTC_TARGET * target, HTC_ENDPOINT_ID endPointId,
struct sk_buff *skb, void *cookie);
#endif
int
HTCBufferSend(HTC_TARGET * target, HTC_ENDPOINT_ID endPointId,
u8 * buffer, u32 length, void *cookie);
/* target - IN, endPointId - IN, buffer - IN, length - IN, cookie - IN */
#if 0
int
HTCSkbSend(HTC_TARGET * target, HTC_ENDPOINT_ID endPointId,
struct sk_buff *skb, void *cookie);
#endif
#####################################################
And that's as far as I've gotten to date. Is anyone more familiar with
the code that can give me some background on the above? Am I barking up
the wrong tree?
And also, would it be worth our while to fire this off to Luis and Pavel
at Atheros? They're the lead guys on ath9k, they might be able to gin
up some help, or at meast point us in the right direction.
tia,
Jason.
[1] - http://n2.nabble.com/Weekly-Engineering-News-37-2008-td1095866.html
More information about the openmoko-kernel
mailing list