Bár hazánkban nem olyan elterjedtek (elméletileg) a 802.11a szabványt használó kártyák, biztos vannak, akiket érdekel a hír. Reyk Floeter tegnap este/ma reggel sikeresen küldött csomagokat a kísérleti driverrel.Reyk Floeter jó ideje fejleszti a GPL-es drivert az Atheros chipsetes kártyákhoz (a 802.11a-t támogató kártyák kb. 99%-a ilyen), ami azért is fontos, mert még closed-source drivert se adtak ki hozzájuk, amelyek többnyire cégeknek érhetőek el kb. $50k áron. Tegnap este/ma reggel fordult a kocka, Reyk sikeresen küldött csomagokat a kísérleti driverrel.
Íme az e-mail:
Date: Wed, 21 May 2003 23:24:06 +0200
From: Reyk Floeter
Reply-To: AR5k 802.11a GPL driver for GNU/Linux
To: AR5k 802.11a GPL driver for GNU/Linux
Subject: [ar5k] successfully sent packets (TXOK)
On Wed, May 21, 2003 at 11:27:26AM +0200, Enrik Berkhan wrote:
> > * tx implementation (-> TXERR)!
>
> Any idea what could be wrong? Is it the tx_queue setup?
>
> What I can see is the following:
>
> 1. packet -> TXERR
> 2. packet -> tx doesn't even start (tx reset needed after TXERR?)
> 3. packet -> tx_active == 1, vt_ar5k_start_xmit is called continously
>
tx worked!
i successfully sent some packets recognized by the access point. i
modified some parts of the tx frame descriptor settings and the
initial card reset. the tx desc value 'buf_len' has to be smaller than
the value 'frame_len'... frame_len is the size of the buffer including
IV, and WEP/AES/... and the checksum. i first thought that 'buf_len'
has to be the len of the whole allocated descriptor buffer...
you can find all the latest changes in the cvs tree. i'll release a
new upstream version as soon as i implemented a working tx queue. the
current cvs code is only capable of sending authentication frames to
the specified accesspoint hardcoded in the start_xmit function.
the current implementation only works for ar5000 (ar5210)- based
cards. as soon as i have a ar5001 (ar5211)- based card, i'll add
support for the newer chipset. but the ar5211 has a more complex tx
interface. ie., it provides a QCU (queue controlling unit) with up to
ten tx queues. in opposite, the ar5210 has only two tx queues, one for
data frames and one dedicated for beacon sending.
kernel messages:
(after 'ifconfig wlan0 $SOMEIP up &&
iwconfig wlan0 essid $ESSID &&
ping $OTHERIP')
step 1: sent tx frame
---snip---
vt_ar5k (wlan0): [5] tx (frm_len=36,hdr_len=24,xmit_rate=9,ant=0,clr=0,type=0,intr=1,buf_len=32,more=0,buf=82784256)
---snap---
step 2: interrupt, cleanup tx queue
---snip---
vt_ar5k (wlan0): [6] interrupt... AR5K_IMR_TXOK
vt_ar5k (wlan0): [6] tx (done=1,seq=2,acksig=64,ok=1,eretries=0,underrun=0,filtered=0,srcount=2,lrcount=0,timestamp=45947)
---snap---
step 3: received response from accesspoint
---snip---
src/wdev.c: received deauthentication frame(reason 0x00 ' Reserved reason ')
---snap---
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
i currently only have an ap based
on atheros' ar5000 reference
design. it has a very low-quality
software implementation
with a lot of bugs... ,(.
next i'll implement all the stuff needed for successfully associating
to the access point in ieee 802.11 station mode and an enhanced ap
scanning ability including beacon timeout checking.
reyk
--
/* .vantronix|secure systems - (research & development)
* reyk floeter - friendly known free software engineer
* reyk@vantronix.net - http://team.vantronix.net/reyk/
*/
_______________________________________________
ar5k mailing list
ar5k@lists.vantronix.net
https://lists.vantronix.net/mailman/listinfo/ar5k