Attached is 1-st iteration for generic 802.11 stack framework. Based on code from Dave. I make it compile for 2.6 and wrote simple skeleton for native 802.11 driver. This skeleton is able to simulate
Why this change? -extern void hh_data_is_too_small(void); +static void hh_data_is_too_small(void) +{ + printk(KERN_ERR "hh_data_is_too_small\n"); +} We don't define the function because it is meant t
My misunderstanding. Sorry. As above. My editor did it for me. I'll be more carefull to check this behind the scene things. Maybe, I'll do one patch to do all spaces accordingly to kernel coding styl
All existing wireless drivers use the standard ethernet MTU. I really think it is supposed to be 1500. That's why I left it at ether_setup()'s setting. Upper layers really want to see a 1500 byte sta
I'd like to evaluate possibility to use your stack for real driver. 80211 have some specifics thus we need to answer following questions: - some devices handles almost all MAC in firmware; some - ha
Use function pointers for the handlers that can be overridden by the driver, or something similar like that. Start with "pure %100 software" stack, then once that is fully functional work back to add
select DS> > AP from list), or for information purposes (sniffer). What is your vision how DS> > to do this? I.e. provide some standard PHY header before MAC header, out of DS> > band (use cb?) to D
be DS> > specified per packet. So question ramains: how to specify PHY info per skb. DS> This should be done in generic way. This information used to communicate berween particular driver and generic
communicate DS> > berween particular driver and generic stack. For example, Rx PHY info and Tx DS> > status info should be used for in-stack generic rate scaling algorithm. DS> > exceed DS> > this s