[REPOST: [Airjack-hackers] initial details of driver API...]

[Abaddon <ab...@80...>]

ill be reposting messages like this all night as people get on the list,
bare with me until everyone is signed up...

--Abaddon

-----Forwarded Message-----

From: Abaddon <ab...@80...>
To: air...@li...
Subject: [Airjack-hackers] initial details of driver API...
Date: 05 Jul 2003 13:55:23 -0500

i will start to post details of the driver API's tonight on this list...

as it stands there are three sections of code in airjack2...

the first layer is the os layer, this defines a number of things like
os_copy_from_user() and os_spin_lock(), etc, the rest of the sections
should never call an os dependant function directly if it can at all be
avoided, this way we dont have to rewrite everything...

the second layer is the bus abstraction, this is how airjack2 plans on
working for so many different bus types, anything regarding talking to
the card (not what you say, but how you say it) will go through the bus
abstraction, so it shouldn't different code (for the most part) for
cardbus as it is for pcmcia (however there are differences in such
things as DMA handling where available)...also there is a device event
handler that is common to all bus types abstracting away handling of
such things as device insert and removal...a bus is described by a
struct ieee80211_bus

the third layer is the hardware (or driver) layer, this is just a
listing of callbacks to control the card, these are pretty low level
callbacks (see below for some exceptions) so you dont really need to
know much about how the driver is working, it just tells airjack how to
make the card do some basic things...this is described by the a=20
struct ieee80211_drv

the fourth layer is the airjack system itself, this mostly takes the low
level abstractions from the bus, the os and the hardware layers and
smashes them together at high speeds to make a driver...this consists of
functions to allocate and register bus's drivers and actual
devices...this also consists of a number of generic function callbacks
that i expect most drivers to use and thus they wont need to do anything
but fill in very low level function stubs...however if there is some
high level function that the airjack system simply wont handle, then all
drivers can override any airjack generic callback on driver
registration...each individual device (combination of bus and driver,
allocated and registered to represent an actual physical device thats
been inserted) is represented by a=20
struct ieee80211_dev

so to recap, the major structures are:

struct ieee80211_bus:
this describes (and abstracts away) a bus (e.g. pcmcia, pci, cardbus,
usb, or compact flash), this should be as os independent as it can be
guys...

struct ieee80211_drv:
this describes an individual driver for a chipset, while this is usually
only going to have low level hardware callbacks that differ from other
drivers, it does hold all the callbacks for card access and event
management, so you can override them if needed, but you should strive to
only have to use the low level hardware callbacks to make this work...

struct ieee80211_dev:
this describes an actual device that has been inserted into the machine,
it combines both a bus and a hardware driver with the indevidual device
stats, status, capabilities info, and config...


a word on user space interfaces...the new airjack will include an
airjack specific interface, and that is all you need to configure any
airjack device, this is desirable so that the same code can easily
configure a linux airjack driver, as well as a bsd airjack driver...

however, every os abstraction layer will also be required to support
that platforms existing legacy configuration interface...this is so that
legacy apps will still work, and it will easy the switch...i dont plan
on removing this any time soon so you can count on it being there...

the new airjack drivers are going to support all the operating mode
including station, adhoc, adhoc master (where applicable), host AP, and
a couple special airjack modes (ill describe that in a later email),
obviously not all drivers will support all modes but we should do our
best to make them all work...for releases this weekend dont expect
anything but station mode and airjack modes to work...also dont expect
encryption of any kind to work at this point...

i will in the future be supporting all encryption modes, plus WPA,
tkip/mic, aes, and many more as well as a number of other user
development forms (such as wep with a repaired KSA, etc)...it should be
made easy for all cards to use all forms available even if their
hardware does not (we will need to set many of them in host encrypt mode
and do it on the host cpu in those cases)...we should make it easier for
people to develop such techniques on airjack drivers...

one of the reasons why security has been so bad on wireless had been in
part due to the difficulty of average developers getting access to test
out their ideas and have their code supported on a large number of
platforms,one of the goals of airjack is fix that problem by making it
easy for developers and researchers to rapidly develop and prototype new
security features for 802.11 networks, as well as prototype research
tools to test the security of existing security measures...

actual code details for this API (enough to start you working on chipset
drivers) will be released late to night to this mailing list...this and
other emails i will repost a few times because i know many people are
not signed up yet (still hung over from the 4th and whatnot ;)...

timball:
start gathering up atmel chipset info if you could, ill email out the
hardware layer structure to the list tonight id like to try to get this
working on those crappy atmel cards you have at about the same time i
finish my port to prism2 and aironet...also, and maybe more importantly
i want frequency hopping support on that symbol card of yours (please
tell me you still have it), so track down as much as you can on that as
well...

anyone else:
even though i just said i was porting aironet driver to this, i cant
release those that i am writing due to conflicting NDAs, i am however
writing it up privately not for release to verify that it can be done
easily by someone else...

i am currently looking for volunteers to take exiting GPL'ed aironet
code and porting it to the airjack framework...

i am also under NDA with atheros, and as such i cant release my ar5k
drivers, however i am writing them and i am testing out the cardbus bus
layer to ensure that development of them is very possible and pretty
easy...there are GPL'ed drivers out for these so i am hoping to get
someone to help with these as well (i have one taker for this, but i
really want this support before the DefCon release guys)...

as for broadcom and intersil 802.11a/g chipsets, i currently have no
NDAs so i am going to be reverse engineering the windows drivers (did
you hear me DMCA *flips DMCA off*) and getting this going for those as
well...anyone that wants to help with that is welcome...

any questions should be directed to this list if possible guys...expect
me to be off and on all the rest of the weekend as i have alot more code
to finish to make my monday commitment...

--Abaddon