Ath5k

Toto je kopie textu z wiki.nfx.cz

Úvod

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

• funguje bez problémů
• od verze 7.2 je i kompletně open-source (včetně HALu)
• od ledna 2009 má základní podporu přístupové metody TDMA, která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

Finance

Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)

• Klfree
• Unart
• Czf-praha
• Unhfree
• KHnet
• Bubakov.net

Kontaktní osoby

Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:

• KLFree: Jast ?
• UnArt: Dulik
• Czf-praha: 8an ?
• Unhfree: Litin ?
• Bubakov.net:

Návrh harmonogramu prací

Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

Administrativa

Co je potřeba udělat hned na začátku:

1. Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz mailing list ath5k.

Testy/úpravy modu AP

ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona hostapd, který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

TX power

Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

• ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
• Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
• Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

Implementace

Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

Ambient noise immunity - ANI

Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení najdete zde

Ve [url=http://madwifi-project.org/ticket/705]starém Madwifi[/url] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [1]nadšeného výskotu ostatních vývojářů] ath5k).

Ruční testování - podprojekt "měřící pracoviště"

Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme. A nemáme na ně ani peníze. Více v mailech.

Automatické testování - podprojekt "WiFi pískoviště"

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: Automation of testing using mac80211_hwsim and Orbit.

Projekt Orbit (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:

1. do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
2. zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
3. náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
4. jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.