Need help to write a new driver for a new wireless device (not yet in the market).

[Sriharsha Vedurmudi]

Friends,
 I am a novice in Wireless drivers (did some Ethernet based drivers
though). I have a new 802.11b/g chip (not publically available yet)
with its internal documentation and need help from the community to
write a driver for it in Linux.
 I am using an Linux port (kernel 2.6.19-2) on an ARM based SoC (with
WE version 21). To begin with I have implemented the basics and my
system now associates with open mode AP and WEP based AP. Now, I want
to test out its WPA-PSK functionality. Are the following ioctls
sufficient or do I need to implement more (apart from the basic ones)?
SIOCSIWMODE,
SIOCSIWGENIE,
SIOCSIWAUTH,
SIOCSIWESSID

Also, how do I use Wireless_Events (I am not able to find any proper
documentation for the same).
Apart from this, is there some documentation (like 'Linux Device
Drivers') that specifically tutors someone at writing a driver for a
wireless station?

Yours sincerely,
VSH.

[Christian Bünnig]

Hi,

some notes concerning wireless events ..

Sriharsha Vedurmudi wrote:

> Friends,
>  I am a novice in Wireless drivers (did some Ethernet based drivers
> though). I have a new 802.11b/g chip (not publically available yet)
> with its internal documentation and need help from the community to
> write a driver for it in Linux.
>  I am using an Linux port (kernel 2.6.19-2) on an ARM based SoC (with
> WE version 21). To begin with I have implemented the basics and my
> system now associates with open mode AP and WEP based AP. Now, I want
> to test out its WPA-PSK functionality. Are the following ioctls
> sufficient or do I need to implement more (apart from the basic ones)?
> SIOCSIWMODE,
> SIOCSIWGENIE,
> SIOCSIWAUTH,
> SIOCSIWESSID
>
> Also, how do I use Wireless_Events (I am not able to find any proper
> documentation for the same).

What exactly do you mean by "use"? Listening for them in a user space
application or raising them within the driver?

Events are implemented with netlink sockets to transfer them from the
driver to user space.

Example code for listening can be found in the source code of the
wireless tools:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#latest
and there in the file iwevent.c

Example code for raising an event can be found, for instance, in the
Madwifi code:
http://madwifi.org/browser/trunk/net80211/ieee80211_input.c and there in
the function iwspy_event(), near line 145

However, I am not that up to date about wireless driver development but
doesn't the generic Linux 80211 stack implement all the event things?

> Apart from this, is there some documentation (like 'Linux Device
> Drivers') that specifically tutors someone at writing a driver for a
> wireless station?
>
> Yours sincerely,
> VSH.

[Sriharsha Vedurmudi]

Hi Christian and Others,
 I am facing an issue while trying to add a WPA/RSN IE to an event. I
tried to follow the airo card (driver in airo.c) for this, but in that
firmware, the entire IE is being sent raw to iwe_stream_add_point()
function. But in our case, the IE is parsed and filled in our private
data structure. Is there any way in WE ver 21 where I can pass the WPA
IE into some structure and then send the event to wpa_supplicant?

Regards,
Harsha.

On 9/28/07, Christian Buennig <masala@...> wrote:

> Hi,
>
> some notes concerning wireless events ..
>
> Sriharsha Vedurmudi wrote:
> > Friends,
> >  I am a novice in Wireless drivers (did some Ethernet based drivers
> > though). I have a new 802.11b/g chip (not publically available yet)
> > with its internal documentation and need help from the community to
> > write a driver for it in Linux.
> >  I am using an Linux port (kernel 2.6.19-2) on an ARM based SoC (with
> > WE version 21). To begin with I have implemented the basics and my
> > system now associates with open mode AP and WEP based AP. Now, I want
> > to test out its WPA-PSK functionality. Are the following ioctls
> > sufficient or do I need to implement more (apart from the basic ones)?
> > SIOCSIWMODE,
> > SIOCSIWGENIE,
> > SIOCSIWAUTH,
> > SIOCSIWESSID
> >
> > Also, how do I use Wireless_Events (I am not able to find any proper
> > documentation for the same).
>
> What exactly do you mean by "use"? Listening for them in a user space
> application or raising them within the driver?
>
> Events are implemented with netlink sockets to transfer them from the
> driver to user space.
>
> Example code for listening can be found in the source code of the
> wireless tools:
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#latest
> and there in the file iwevent.c
>
> Example code for raising an event can be found, for instance, in the
> Madwifi code:
> http://madwifi.org/browser/trunk/net80211/ieee80211_input.c and there in
> the function iwspy_event(), near line 145
>
> However, I am not that up to date about wireless driver development but
> doesn't the generic Linux 80211 stack implement all the event things?
>
> > Apart from this, is there some documentation (like 'Linux Device
> > Drivers') that specifically tutors someone at writing a driver for a
> > wireless station?
> >
> > Yours sincerely,
> > VSH.
>
>

[Sriharsha Vedurmudi]

Hello Benjamin,
 As much as I want to share the spec, but I am under strict legal
agreements not to share it with anyone (not even outside our team).
Another case of corporate dictatorship, but I am helpless. Sorry about
it.
 But the good news is that, this particular chip might not hit the
markets, atleast not in volumes in the coming future.

That said, can you please let me know the following:
1. What value of ssid_scan should I use if I want to use ap_scan=2
(let the driver connect to the AP directly when wpa_supplicant issues
ioctl to connect to an SSID.

2. I implemented all the ioctls, mandated by WE/wpa_supplicant for
using WPA-PSK. But I observe two things when I try:
$ wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -d

a) I don't see any printk messages that I put inside my ioctls (not
even the ones that churn out when the control enters the particular
ioctl. Why is it so?
b) The output by wpa_supplicant shows the AP correctly in the output
list but it shows its wpa_ie_len as 0 (even though in the SIOCGIWSCAN
ioctl handler, I am using iwe_stream_add_point to add the wpa IE
buffer).

Thanks and Regards,
Sriharsha.

On 10/2/07, Benjamin Close <Benjamin.Close@...> wrote:

> Hi Harsha,
>     I'm a wireless driver developer for FreeBSD. Do you think there
> would be an chance of providing the spec for the chipset so the *BSD
> community might also be able to benefit from the card when it is released?
>
> Cheers,
>     Benjamin
>
> Sriharsha Vedurmudi wrote:
> > Hi Christian and Others,
> >  I am facing an issue while trying to add a WPA/RSN IE to an event. I
> > tried to follow the airo card (driver in airo.c) for this, but in that
> > firmware, the entire IE is being sent raw to iwe_stream_add_point()
> > function. But in our case, the IE is parsed and filled in our private
> > data structure. Is there any way in WE ver 21 where I can pass the WPA
> > IE into some structure and then send the event to wpa_supplicant?
> >
> > Regards,
> > Harsha.
> >
> > On 9/28/07, Christian Buennig <masala@...> wrote:
> >
> >> Hi,
> >>
> >> some notes concerning wireless events ..
> >>
> >> Sriharsha Vedurmudi wrote:
> >>
> >>> Friends,
> >>>  I am a novice in Wireless drivers (did some Ethernet based drivers
> >>> though). I have a new 802.11b/g chip (not publically available yet)
> >>> with its internal documentation and need help from the community to
> >>> write a driver for it in Linux.
> >>>  I am using an Linux port (kernel 2.6.19-2) on an ARM based SoC (with
> >>> WE version 21). To begin with I have implemented the basics and my
> >>> system now associates with open mode AP and WEP based AP. Now, I want
> >>> to test out its WPA-PSK functionality. Are the following ioctls
> >>> sufficient or do I need to implement more (apart from the basic ones)?
> >>> SIOCSIWMODE,
> >>> SIOCSIWGENIE,
> >>> SIOCSIWAUTH,
> >>> SIOCSIWESSID
> >>>
> >>> Also, how do I use Wireless_Events (I am not able to find any proper
> >>> documentation for the same).
> >>>
> >> What exactly do you mean by "use"? Listening for them in a user space
> >> application or raising them within the driver?
> >>
> >> Events are implemented with netlink sockets to transfer them from the
> >> driver to user space.
> >>
> >> Example code for listening can be found in the source code of the
> >> wireless tools:
> >> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#latest
> >> and there in the file iwevent.c
> >>
> >> Example code for raising an event can be found, for instance, in the
> >> Madwifi code:
> >> http://madwifi.org/browser/trunk/net80211/ieee80211_input.c and there in
> >> the function iwspy_event(), near line 145
> >>
> >> However, I am not that up to date about wireless driver development but
> >> doesn't the generic Linux 80211 stack implement all the event things?
> >>
> >>
> >>> Apart from this, is there some documentation (like 'Linux Device
> >>> Drivers') that specifically tutors someone at writing a driver for a
> >>> wireless station?
> >>>
> >>> Yours sincerely,
> >>> VSH.
> >>>
> >>
> >
> >
>

[Daniel Rose]

Sriharsha Vedurmudi wrote:
> Hello Benjamin,
>  As much as I want to share the spec, but I am under strict legal
> agreements not to share it with anyone (not even outside our team).
> Another case of corporate dictatorship, but I am helpless. Sorry about
> it.


Much as I usually don't like to chime in with a negative comment, I will anyway.  It's OK in this case because I don't know enough to be able to help anyway, so you're not missing out on anything.

If a company wishes to develop something, and not share the details with the community, why should anyone in the community help the company?

If this hardware takes off, then there will be more hardware around that requires "tainting" the kernel, especially at a time when we are having wins moving the other way (ATI, for example).

If it doesn't, then we're all wasting our time; even the software that might potentially be useful to someone else will be discarded.


>  But the good news is that, this particular chip might not hit the
> markets, atleast not in volumes in the coming future.
>

How is that good news?  Why make it if you won't sell it?

[vk2tds]

Hello All,

This post is a bit longer than I had wanted. Still, it says a lot too...

I truly wish I could help Sriharsha on this issue. I just do not have the
time, or the knowledge of the internals of the Linux wireless driver. It
would be fun for me to learn, but I have not got the time at the moment. It
has been 10 years since I worked on a Wireless driver for Linux. And in that
time things have changes a lot (Yes my friend, there was Wireless back in
1997! I did write a paper on this
(http://www.radio-active.net.au/webran/articles/papers/dcc1997.doc; and I
have been using Linux since Minix)

So, why should we help him? Well, by answering the questions we all learn.
Phil Karn, KA9Q, (Karn's Algorithm for exponential packet backoff) is famous
for saying that the best way to learn something is to have to explain it to
someone else. I totally agree with that. The questions that Sriharsha is
asking are reasonable to understand the low level wireless interfaces. And
that improves the knowledge within the community.

And from I have already learned from the Questions. And the answers would be
very useful.

As for the whole Open Vs. Closed source issue for wireless drivers. I have
heard a heap on the issue from people like Bob McGwyer, Bruce Perens and
Bdale Garbe, and discussed the issue with some of these people. If you have
no idea who they are then you might want to do a bit of research. Each are
involved in some way with the Software Defined Radio and Open Source world.
I am also on the board of a Wireless Non-Profit R&D Organisation in the USA
- an organization whose annual conference proceedings was used as the prior
art to stop the patenting of Java, and who co-developed the protocol that
the name SSID with WiFi was borrowed from (AX-25 is the protocol, and TAPR
is the Organisation). Then there is the work of Matt Ettus and Gerard
Youngblood...

The area of Software Defined Radios needs a re-thinking of the entire Open
Source world. In many cases there are legal reasons for full source code not
being released. I am not talking about NDA's here. I am talking about
serious restrictions where a company might be liable to a fine in excess of
$250,000 *each time* they permit their device to be used with modified
source code.

There is a vast legislative difference between a video card and a wireless
card. There is no constitutional coverage for video cards in the Australian
constitution, but there is for Wireless cards Section 51(V). There is
specific legislation applying to wireless cards, as opposed to video cards.
This would include the "Radiocommunications Act 1992", and maybe the
"Telecommunications Act 1997"

In Australia, what people believe is unlicensed is actually covered under a
class license. The importer needs to certify that they meet certain
technical requirements with the device. If the device is modified in any way
the class license no longer applies, and the device is operating illegally.
This could include operating with a different antenna, power amplifier, or
modified software. You see, when you change the firmware in these devices,
the regulatory filings no longer apply.

And I am sure that many people will tell you that these days the drivers
actually upload firmware to devices. Regardless, some of the settings or
combination of the settings will cause situations where the device can
operate outside legal limits. And a manufacturer that allows this can be in
a heap of trouble.

Many people take the "don't ask, don't tell" attitude to wireless. This is
wrong. Things are messy. Governments are trying to restrict high speed DAC
and ADCs for these type of reasons. Thankfully we have some people fighting
that.

What I am saying is that there is a case for closed source wireless drivers.
There is also a case for open source drivers. But to say that a person
should not be helped because the drivers will be closed source. Well, that
is short sighted. After all, how are you then going to reverse engineer the
driver to do cool stuff :-)

Darryl Smith VK2TDS
http://www.radio-active.net.au


-----Original Message-----
From: wireless-bounces+darryl=radio-active.net.au@...
[mailto:wireless-bounces+darryl=radio-active.net.au@...] On
Behalf Of Daniel Rose
Sent: Wednesday, 3 October 2007 7:43 AM
To: wireless@...
Subject: Re: Need help to write a new driver for a new wireless device (not
yet in the market).

Sriharsha Vedurmudi wrote:
> Hello Benjamin,
>  As much as I want to share the spec, but I am under strict legal
> agreements not to share it with anyone (not even outside our team).
> Another case of corporate dictatorship, but I am helpless. Sorry about
> it.


Much as I usually don't like to chime in with a negative comment, I will
anyway.  It's OK in this case because I don't know enough to be able to help
anyway, so you're not missing out on anything.

If a company wishes to develop something, and not share the details with the
community, why should anyone in the community help the company?

If this hardware takes off, then there will be more hardware around that
requires "tainting" the kernel, especially at a time when we are having wins
moving the other way (ATI, for example).

If it doesn't, then we're all wasting our time; even the software that might
potentially be useful to someone else will be discarded.


>  But the good news is that, this particular chip might not hit the
> markets, atleast not in volumes in the coming future.
>

How is that good news?  Why make it if you won't sell it?

[Daniel Rose]

Darryl Smith wrote:
> Hello All,
>

<SNIP> (no offence!)

>
> What I am saying is that there is a case for closed source wireless drivers.
> There is also a case for open source drivers. But to say that a person
> should not be helped because the drivers will be closed source. Well, that
> is short sighted. After all, how are you then going to reverse engineer the
> driver to do cool stuff :-)
>
I agree. I see the problem, I think.  We can't lock the legally compliant code into hardware because firmware updates are a good thing and we don't want to lose that capability.  You could put code in hardware to handle all the different national rules, and allow the driver to select the nation, but that's irrelevant.

It sounds like a murky area; a user can select the wrong country and be in breach of the technical requirements, can't they?

In any case, I agree that selling open radio comms hardware that allows the users to do all sorts of things could be bad on a large scale, but I'd assume that the hardware required can still be sourced anyway by those keen enough to get it, or make it themselves.  I saw some neat plans a while ago for a radio receiver that generates an EM field, used as an antenna.  It essentially harvests the power from the local radio signal, giving the owner a (dangerous) net power gain, at the cost of a resulting radio shadow over some significant area behind the rig, so people so like to mess with this stuff and I see why we don't want spectrum trashed with all kinds of stuff, whatever the specific licencing of the spectrum or the software.

[Sriharsha Vedurmudi]

Hello Daniel,
 the simple reason that the community helps me is that I will be in a
position to help someone else stuck with similar problems. I believe a
community is a community of people not organization-to-organization. I
trust you can understand that every developer in this world cannot
belong to an organization that opens up all their IPs to the OS
community, some unfortunate ones like me belong to companies that
choose not to open up their IPs due to whatever reasons they believe
are true.

 The second question you asked, 'why does the company make the chip
that doesn't sell volumes (repeat volumes) in the market'. Well, there
can be 'n' reasons for it. It might be making this chip just as a
proof of concept for something, or might be targetting this chip at a
very small market or finally it is not complete yet. If the chip
finally succeeds to come into the open market, I dont see a reason why
they wouldn't want open source drivers of it out, but I don't run the
company nor have a say in its strategic decisions.

 Rest assured, when I start my own company, I'll definately give/take
open source software and share my code with everyone.

Regards,
Sriharsha.



On 10/3/07, Daniel Rose <drose@...> wrote:

> Sriharsha Vedurmudi wrote:
> > Hello Benjamin,
> >  As much as I want to share the spec, but I am under strict legal
> > agreements not to share it with anyone (not even outside our team).
> > Another case of corporate dictatorship, but I am helpless. Sorry about
> > it.
>
>
> Much as I usually don't like to chime in with a negative comment, I will anyway.  It's OK in this case because I don't know enough to be able to help anyway, so you're not missing out on anything.
>
> If a company wishes to develop something, and not share the details with the community, why should anyone in the community help the company?
>
> If this hardware takes off, then there will be more hardware around that requires "tainting" the kernel, especially at a time when we are having wins moving the other way (ATI, for example).
>
> If it doesn't, then we're all wasting our time; even the software that might potentially be useful to someone else will be discarded.
>
>
> >  But the good news is that, this particular chip might not hit the
> > markets, atleast not in volumes in the coming future.
> >
>
> How is that good news?  Why make it if you won't sell it?
>