[ath9k-devel] limited interface of mac80211 to drivers

[ath9k-devel] limited interface of mac80211 to drivers

[abhinav narain]

hi,
I am working on ath9k device driver.
I want to pass some driver data to the userspace
the most crucial point is transferring skbuff from  ath_rx_tasklet() to
ieee80211_rx() using struct ath_hw.

But there is no way to pass any extra information ... is there any void *
variable where I can store the data of ath9k driver and receive it in
mac80211 subsystem ?
I can then transfer it to userspace easily.

I have another doubt with the evolving kernel subsystem,  I cannot use
ioctl calls to set a particular channel to listen to ?
And I am still using raw socket to read the frame in userspace ...
any hints regarding this will be very helpful

-Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120221/e245e88b/attachment.htm 

[ath9k-devel] limited interface of mac80211 to drivers

[Daniel Smith]

Hi Abhiav,

On 2/21/2012 11:42 PM, abhinav narain wrote:
> hi,
> I am working on ath9k device driver.
> I want to pass some driver data to the userspace
> the most crucial point is transferring skbuff from  ath_rx_tasklet() to
> ieee80211_rx() using struct ath_hw.
>
> But there is no way to pass any extra information ... is there any void *
> variable where I can store the data of ath9k driver and receive it in
> mac80211 subsystem ?
> I can then transfer it to userspace easily.
I had a similar issue and the approach I took was to add a vendor 
radiotap header to the beginning of the skb buffer in ath9k. Then in 
mac80211 I combined the vendor radiotap header with the main radiotap 
header added by mac80211. The gotcha to watch out for is that you need 
to ensure enough space is allocated in the skb.
>
> I have another doubt with the evolving kernel subsystem,  I cannot use
> ioctl calls to set a particular channel to listen to ?
> And I am still using raw socket to read the frame in userspace ...
> any hints regarding this will be very helpful
Ath9k is a mac80211 based driver, you should be using the cfg80211 
netlink-based API to control the device. Actually you should use it for 
all wireless devices because the WEXT ioctl framework is deprecated. As 
for the raw socket, if you are looking for an API to abstract the packet 
sniffing then take a look at libpcap.

v/r,
dps

[ath9k-devel] limited interface of mac80211 to drivers

[abhinav narain]

>
>
> > variable where I can store the data of ath9k driver and receive it in
> > mac80211 subsystem ?
> > I can then transfer it to userspace easily.
> I had a similar issue and the approach I took was to add a vendor
> radiotap header to the beginning of the skb buffer in ath9k. Then in
> mac80211 I combined the vendor radiotap header with the main radiotap
> header added by mac80211. The gotcha to watch out for is that you need
> to ensure enough space is allocated in the skb.
>
Great !
I am doing something similar but only after the frame has arrived in
mac80211 subsystem by ieee80211_rx().
The doc :http://kernel.org/doc/htmldocs/80211/API-ieee80211-rx.html
says the skb must start with a with an IEEE 802.11 header ...
so, I did not touch the skb in driver, else skb will start with my header
instead of 80211.
Is it okay to add a header in driver(ath9k) and give it to ieee80211_rx() ?

Also, I hope I don't have to make changes in the control flow of mac80211
apart from monitor/radiotap related functions ...
(Is it possible to have a look at your code.. to get hints ?)


> >
> > I have another doubt with the evolving kernel subsystem,  I cannot use
> > ioctl calls to set a particular channel to listen to ?
> > And I am still using raw socket to read the frame in userspace ...
> > any hints regarding this will be very helpful
> Ath9k is a mac80211 based driver, you should be using the cfg80211
> netlink-based API to control the device. Actually you should use it for
> all wireless devices because the WEXT ioctl framework is deprecated. As
> for the raw socket, if you are looking for an API to abstract the packet
> sniffing then take a look at libpcap.
>
> I noticed one thing, when I used libpcap simply.. then I did not get any
frames at all ..
I then created a raw socket and read through it to get some test data i was
sending from the kernel... ( I read libpcap code long back and
essentially that also does exactly the same .. but no Idea why that
happened.
I had a bpf filter for beacon frames so that pcap is not exacted a lot.


To bring another concern to notice is, If I read all the packets on Netgear
router (from my raw socket) ...
Am I not going to drop packets ?
Or the router can sniff and work as a router both well at the same time ?

Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120222/f583a0d9/attachment.htm