On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote:
LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote:
LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
LR> > LR> RFC: what are the chances we can implement our own generic
"softmac" that may LR> > LR> be usable by the different chipsets out there?
LR> >
LR> > Coming days, I will submit "framework" consisting of stack based on
Dave's LR> > code and debug driver which will be able to imitate Rx. I have
working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces
stack-driver and LR> > stack-upper layers. It would be great if someone will
do MAC algorithms. I'll LR> > appreciate this for sure.
LR>
LR> But would it be possible? Would it work, if we write our own softmac
LR> interface? Or are softmac interaces/libraries strictly dependent on a
LR> chipset being used?
LR>
LR> Luis
LR>
In idea yes, 802.11 stack should serve any low level driver provided it can
Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The
difference is, 802.11 stack is not written yet, we need to make sure we do it
in smart way and with reasonable assumptions about what low level driver can
do.
Thus far, I assume, low level driver (and NIC, of course) can:
-Tx/Rx arbitrary data and management packets. Control frames generated by NIC.
-NIC can perform scanning and report beacons or probe resp. to the stack.
-NIC can report some basic PHY data per packet: rate, RSSI, maybe something
else.
-NIC accept some basic PHY data per packet on Tx: rate, retry count,
protection, maybe Tx power and some others
-NIC can do crypto transformations on both Tx and Rx. For this, crypto key
need be provided per packet for Tx and some ,mechanism to provide key for
each peer need to be established for Rx.
-NIC may choose to not do fragmentation/reassembly, stack will handle it.
-NIC may have many Tx queues for QoS, it will be able to start/stop each one.
To not raise unsupported expectations: 802.11 stack is only skeleton for now.
I will do interface parts first. For actual algorithms to handle managements
flows, help required. But, I believe it is wise to write these algorithms
once for this stack rather to implement whole stack with each driver.
Vladimir.