Jaderné noviny: Wireless Networking Summit 2006

27. 4. 2006 | Robert Krátký | Jaderné noviny | 4710×

Bývaly časy, kdy bylo nastavení linuxového systému zdlouhavým a problematickým procesem, přičemž nebyla žádná jistota, že daný systém bude fungovat bez velkých potíží. Většina těchto problémů je již léta překonána a do jisté míry lze očekávat, že Linux bude "prostě fungovat". Zbývá však několik problémových oblastí - a bezdrátové síťování je jednou z nich. I když je hardware podporován (což často nebývá), plné zprovoznění bezdrátového připojení může být dost obtížné.

Článek vyšel původně jako součást zpravodajství o jádře na serveru LWN a jako takový by patřil do článku Jaderné noviny - 12. 4. 2006. Kvůli jeho délce jsem jej však zařadil samostatně.

---

V oblasti bezdrátového síťování se však děje hodně. Aby se věci pohnuly dále kupředu, zorganizovaly Open Source Development Labs (OSDL) v Portlandu 6. a 7. dubna setkání vývojářů pracujících na bezdrátovém síťování. Podařilo se tak dát dohromady různorodou skupinu vývojářů z celého světa, z nichž mnozí se setkali poprvé. Účel setkání - načrtnout cestu k vytvoření rozumně fungující implementace bezdrátového síťování v Linuxu - byl, jak se zdá, z větší části naplněn.

Váš redaktor [Jonathan Corbet] měl to štěstí, že se mohl setkání zúčastnit. Následující reportáž je pokusem o shrnutí závěrů setkání - nejedná se o podrobné zápisky minutu po minutě a v průběhu psaní budu muset provést trochu chronologických úprav. Doufám, že z výsledku bude patrné, jak si věci v současné době stojí, a kam budou směřovat v budoucnu.

Historie

Jak podotkl John Linville (nedávno jmenovaný správcem bezdrátového síťování) během našeho rozhovoru, rané bezdrátové adaptéry byly prodávány jako "bezdrátový Ethernet", a vývojáři linuxového jádra s nimi nakládali jako s pomalými, nespolehlivými a nešikovnými ethernetovými adaptéry. Ale bezdrát není Ethernet ani v nejmenším - jde o naprosto odlišné síťovací standardy s vlastními manýry, speciálními funkcemi a jinými potřebami. Nahlížení na bezdrát, jako by šlo o formu Ethernetu, zpomalovalo implementaci podpory zmiňovaných speciálních funkcí a především ztěžovalo vývoj jakékoliv interní podpory v jádře. Každý vývojář, který se pustil do vývoje ovladače pro bezdrátový adaptér, nakonec musel všechno implementovat od nuly. Neexistovalo tedy žádné obecné API pro bezdrátové síťování, žádná ucelená podpora bezdrátových funkcí a kód ovladačů byl nejednotný navzdory množství duplicit.

V roce 1997 se Jean Tourrilhes rozhodl něco se situací provést. Výsledkem byly WE-1 - první verze Linux wireless extensions (rozšíření pro bezdrátové síťování). V té době ještě nebyl žádný 802.11 standard, ale WE API umožňovalo konfiguraci a provoz bezdrátových adaptérů s pomocí jediné sady nástrojů. Jeanovy wireless extensions jsou i nadále hlavními utilitami pro správu bezdrátových adaptérů, i když většina uživatelů je nahrazuje grafickými rozhraními.

Vývoj wireless extensions pokračoval - WE-9 podporovaly v roce 1999 nový standard 802.11. Minulý rok začleněné WE-18 přidávají podporu WPA (WiFi Protected Access - chráněný přístup). Aktuální verze WE-20 obsahuje nové rozhraní založené na netlink, které má v budoucnu nahradit současné ioctl() API.

Ačkoliv vývoj pokračuje, všeobecně převládající názor naznačuje, že doba, po kterou byly wireless extensions považovány za užitečné, se chýlí ke konci. Náhradní API - které zatím neexistuje - by mělo pracovat s celým stackem pro bezdrátové síťování, místo aby bylo rozhraním pro přímou komunikaci z nízkoúrovňovými ovladači. Avšak bez ohledu na to, jak to dopadne, je pravděpodobné, že wireless extensions tu budou ještě dlouho.

Současný stav

Současná snaha o vytvoření řádného bezdrátového stacku pro Linux začala v roce 2004, když Jeff Garzik oznámil založení speciálního stromu pro bezdrátové síťování, který byl zpočátku naplněn kódem HostAP. Začlenění HostAP umožnilo podporu relativně nových síťových karet a využívání Linuxu jako bezdrátového přístupového bodu. Vytvoření stromu pomohlo dát věci do pohybu, ale HostAP nakonec nenaplnil tak docela očekávání. Konkrétně není v HostAP podpora pro karty, které potřebují implementaci softwarové MAC ("softmac"). Nemálo dnešních karet však s mnoha nízkoúrovňovými operacemi spoléhá na hostitelský software; tyto karty nemohou být stackem pro bezdrátové síťování současného (2.6.16) jádra podporovány.

Výsledkem je, jak řekl John Linville, implementace, která podporuje "vše, co je zastaralé". Některé karty se těší větší podpoře než jiné. Ze současného hardwaru stojí za zmínku hlavně sada Intel IPW, která je, díky Intelu, jádrem velmi dobře podporována - ale tyto karty nevyžadují podporu softmac.

V tuto chvíli chybí menší množství okrajově potřebných funkcí, včetně podpory velmi široce používaného hardwaru. Nedostatečná je také uživatelská přívětivost - přes pokroky grafických nástrojů může být konfigurace bezdrátového připojení nepříjemná zkušenost. Nejlépe tyto dva problémy pravděpodobně vystihovala situace na samotném setkání, kde musela přibližně čtvrtina účastníků používat ethernetový kabel, aby se připojili přímo k síti OSDL.

Mezi další problémy patří jednotnost (či spíše její absence) hardwaru - v jádře a v ovladačích mimo strom je neustále několik API se specifickými funkcemi pro různé adaptéry. Dokumentace API jaksi neexistuje; zazněla stížnost, že kniha Linux Device Drivers nepopisuje, jak programovat bezdrátové ovladače. Neexistuje žádný koordinovaný postup pro rozšiřování API. Není podpora pro kvalitu služby - k této otázce se za chvíli vrátíme. V oběhu nejsou žádné testovací balíky pro ovladače. Nad bezdrátovým síťováním se vznáší otázka regulace, která je největší příčinou buď neexistujících nebo nezačleněných ovladačů. Hodně výrobců má prostě pocit, že nemohou zveřejnit informace pro programátory nebo svobodné ovladače a zároveň neporušit regulační režimy na celém světě.

Jádro 2.6.17 však přináší několik vylepšení své podpory bezdrátového síťování. John začlenil jednu z mnoha dostupných implementací softmac - na základě předpokladu, že jako jeden z nejaktivnějších projektů pomůže s vývojem ovladačů. Byl také začleněn ovladač bcm43xx (Broadcom), který softmac používá, a ve vývoji je pár dalších ovladačů založených na softmac. Přesto však převládá názor, že softmac není krokem vpřed; skutečná budoucnost linuxové podpory bezdrátového síťování leží ve stacku od Devicescape.

Devicescape

Devicescape je společnost nabízející množství produktů a služeb týkajících se bezdrátového síťování. V rámci vývoje své nabídky vytvořila Devicescape svůj vlastní linuxový 802.11 stack s několika pěknými funkcemi - včetně dobré podpory softmac a WPA. Nedávno byl stack vydán s GPL a Jiří Benc ho upravil pro jádro. Mnoho lidí jej považuje za nejlepší svobodný stack.

Když spravoval bezdrátový strom Jeff Garzik, postavil se rezolutně proti přechodu na stack od Devicescape s tím, že místo toho by měl být kód v jádře přizpůsoben potřebám. Vypadá to však, že je teď v menšině a John Linville pravděpodobně stack začlení do některé budoucí verze jádra. John spravuje samostatný vývojový strom obsahující Devicescape a několik ovladačů (například bcm43xx) bylo na stack portováno. Na setkání se neobjevil nikdo, kdo by měl proti začlenění Devicescape námitky.

Simon Barber, hacker z Devicescape, o tomto kódu mluvil, oddělilo se i samostatné sezení, které se této otázce věnovalo. Tento stack je velký kus kódu. Uvolněná část obsahuje 802.11 stack, kód "openap" pro přístupové body a modul mostu [brindging] s linkovací vrstvou. Brzy bude uvolněna i další část, která obsahuje zlepšení démona hostapd (mimo jiné i podporu 802.11g; tento kód je teď začleňován), integraci propojování a VLAN a různá vylepšení Ethereal pro vývojáře bezdrátového síťování. Pracuje se také na "kompletní distribuci pro domácí gateway". Všechen tento kód bude zpřístupněn na připravovaném portálu.

Předpokládá se, že na Devicescape stacku bude ještě hodně práce. Interně se skládá z dlouhého seznamu obslužných funkcí, které se starají o rámce (jak datové pakety, tak rámce pro správu 802.11) na jejich cestě od a k adaptéru. V plánech do budoucna figuruje umožnění nahrávání modulů s vlastními obslužnými funkcemi. Více kódu pro správu bude také přesunuto do uživatelského prostoru. Kvůli tomu bude hostapd obohacen o možnosti, které se budou starat autentizaci a správu. V plánu je také spojení hostapd s wpa_supplicant, který má na starosti proces autentizace ze strany klienta; hodně věcí bude zjevně snazších, budou-li tyto dvě funkce sjednoceny do jednoho procesu.

Velké zesložitění bude také zapříčiněno dlouhou řadou budoucích 802.11 standardů. Ty budou postupně schvalovány a bude nutné je podporovat.

Jedna ze zajímavých oblastí vývoje se týká podpory pro kvalitu služby. 802.11 definuje 4 úrovně služby: "hlas", "video", "největší úsilí" a "pozadí". Každá z úrovní má svůj rozsah priorit, rozsahy se překrývají. Všechny hlasové pakety půjdou dříve než pakety pozadí, ale zbytek úrovní bude sdílet dostupnou šířku pásma. Se správnou podporou QoS (Quality of Service - kvalita služby) může uživatel bezdrátu konverzovat pomocí VoIP, streamovat video s "nejčerstvějšími zprávami" o zahlédnutých celebritách ze CNN, stahovat nové jádro z FTP a distribuovat materiály (radši se neptejte jaké) přes Bittorrent. Každá činnost může běžet s vlastní úrovní kvality služby a všechny by měly mít k dispozici nejlepší dostupný výkon.

Některé bezdrátové síťové adaptéry mají podporu kvality služeb ve formě čtyř samostatných přenosových front. Umístí-li hostitel každý paket do příslušné fronty, rozdělí mezi ně adaptér dostupné pásmo tak, aby to odpovídalo kvalitě služby každé z úrovní. Potíž je, že linuxový síťovací stack podporuje pouze jednu přenosovou frontu u každého zařízení. To představuje problém ve chvíli, kdy se zaplní jedna z těch čtyř úrovňových front na zařízení. Neexistuje způsob, jak například jádru říci, že už není možné zařadit do fronty další pakety, ale místo na hlasové pakety by ještě bylo; ovladači nezbývá než uzavřít frontu všem paketům.

Hackeři v Devicescape tento problém obešli s pomocí mechanismu pro ovládání provozu zabudovaného do síťovacího stacku, který běžně operuje na úrovni, kterou kód ovladače nevidí. Díky vytvoření samostatné interní fronty pro každou úroveň služeb dokáže Devicescape stack pro každou úroveň implementovat i samostatnou přenosovou frontu. A ještě lépe, tím pádem je možné nastavit pravidla - které druhy provozu dostanou jakou úroveň - z uživatelského prostoru s použitím běžných nástrojů pro ovládání provozu. Bylo by však fajn, kdyby se toto využití kódu pro ukázněné řazení do fronty zobecnilo a zpřístupnilo i jiným druhům hardwaru.

Další oblast, na které je potřeba pracovat, je definice API pro uživatelský prostor. Není žádné dobře srozumitelné API, které by mohla použít například grafická utilita pro správu bezdrátových spojení ke komunikaci se síťovacím stackem a procesy jako hostapd. Dokonce se ani nemluví o tom, jak by takové API mělo vypadat.

Mezi další otevřené otázky patří obvyklé handrkování o regulacích, neexistence uživatelského prostředí pro správu MAC vrstvy, potřeba lepšího skenování, podpora adaptérů, které spravují MAC hardwarově, podpora ovládání napájení [power management] a přepracování konfiguračního rozhraní. O konfiguraci se starají volání ioctl() a rozhraní /proc. Bylo dáno zřetelně najevo, že kód od Devicescape se do jádra nedostane, dokud bude obsahovat /proc soubory. Také to vypadá, že stack bude muset být upraven, než začne správně fungovat na SMP systémech.

A konečně, přidání řádné podpory bezdrátového síťování do jádra bude obnášet vytvoření specifického net_device typu pro 802.11 zařízení. Také by měla být definována sk_buff struktura specifická pro 802.11. Současný kód stále využívá ethernetové typy a ty další potřebné informace tahá bokem.

Největším problémem však může být toto: co se stane právě začleněnému softmac kódu po začlenění Devicescape? Spousta funkcí je tam duplicitně a nikoho neláká představa spravování dvou různých 802.11 stacků donekonečna. Zřetelně to připomíná situaci s ovladači zvukových karet ALSA a OSS; ALSA měla OSS nahradit, ale odstranění OSS ovladačů se ukázalo jako dost složité. Není jasné, jak zařídit, aby bylo odstranění softmac snazší.

Nástroje

Setkání se účastnili především vývojáři zaměření na jádro, ale mluvilo se i o uživatelských nástrojích; byl tam Daniel Williams, hacker programu NetworkManager. Všichni se shodují v tom, že ačkoliv se během posledních pár let dostupné nástroje výrazně zlepšily, stále je potřeba ujít kus cesty. Konkrétně jde o konfiguraci rozhraní, která funguje bezbolestně až do chvíle, kdy se něco pokazí. Pak je po pohodlí.

Zlepšení situace si bude vyžadovat podporu ze strany jádra. Když se vyskytne problém, musí mít uživatelský prostor informace o tom, co se vlastně stalo. Neexistuje jednotná sada chybových kódů vracených jádrem, které by například mohly sdělit, že není k dispozici potřebný firmware, nebo že poskytnutý WEP klíč není platný. Některé ovladače mají podporu pro větší část současného API než jiné a dokumentace k API v podstatě neexistuje. Lepší skenování by se také hodilo.

Podpora hardwaru

Přestože je nezbytné zdokonalit uživatelské nástroje a síťovací stack, lepší podpora hardwaru je také nutným krokem k implementaci bezdrátového síťování, která "prostě funguje". Některé druhy hardwaru jsou už teď podporovány velmi dobře (Intel a další), jiné budou mít podporu brzy (Broadcom). Na některé (Atheros čipset) si možná ještě počkáme. Stávající ovladač pro Atheros (součástí OpenBSD) má pravděpodobně kód z natolik pochybného zdroje, že šance na začlenění do Linuxu je mizivá. Je tu snaha o dokumentaci Atheros hardwaru na základě dostupného kódu, aby byla v budoucnu možná čistá implementace, ale stále ještě zbývá udělat hodně práce.

V této souvislosti přišla na přetřes otázka dodržování regulačních pravidel. Některé adaptéry (například Atheros) jsou vlastně obyčejná rádia, která lze naprogramovat k provozu úplně mimo specifikaci 802.11. Je-li pro takový hardware vyvinut svobodný ovladač, bylo by Správné zajistit, aby byl s jeho pomocí hardware provozován v souladu s příslušnými předpisy, i když by jej jako takový nešlo certifikovat. Takové testování vyžaduje specializované vybavení a jedná se o několikadenní záležitost. Potřebné vybavení mají k dispozici firmy jako Nokia a některé univerzity, ale v současné době není vyvíjena žádná snaha získat k němu kvůli testování přístup.

Většina vývoje ovladačů se odehrává mimo hlavní strom a vývojáři jádra by to rádi změnili. Jakmile se kód dostane do hlavního stromu, je snazší ho kontrolovat a vylepšovat. Greg Kroah-Hartman nabádal vývojáře ovladačů, aby svůj kód začlenili co nejdříve - i když ještě nefunguje.

Bylo dohodnuto, že komunikace týkající se ovladačů bezdrátových zařízení zůstane prozatím v konferenci netdev. Kdyby se někdy zdálo, že by tato témata mohla provoz netdev zahltit, bude vytvořena nová konference. V blízké budoucnosti bude pravděpodobně také sestavena informační stránka o ovladačích bezdrátových zařízení.

Další otázky

Jedním z cílů setkání bylo vtáhnout více zúčastněných vývojářů do širšího vývojového okruhu jádra. Kvůli tomu se mluvilo také o systémech pro správu verzí, především i git a guilt. Často se připomínal přístup "začlenit co nejdříve".

Stephen Hemminger promluvil o stavu kódu mostů. Mosty vývojáře bezdrátového síťování zajímají - lze je použít pro sdílení spojení a aplikace pro mesh [síťové, pletivové] síťování. Kvůli tomu bude asi propojovací kód přepracován a přesunut do uživatelského prostoru. Stejně jako je teď routování většinou obstaráváno uživatelskými démony, správa mostů - včetně správy spanning [napnutých] stromů - se v budoucnu přesune do uživatelského prostoru.

Někteří zástupci Personal Telco Project měli dostatek kuráže k tomu, aby se během oběda utkali s donáškou pizzy o pozornost vývojářů. Sestavili síť 100 linuxových bezdrátových přístupových bodů po celém Porlandu. Na vývojáře jádra měli několik požadavků, včetně svobodných ovladačů pro Atheros, které neshodí systém, a dobrého bezkonfiguračního mesh síťování. Je to zajímavý projekt, který ukazuje, co zvládne pár "nezaměstnaných geeků".

Celkově bylo setkání optimistickou akcí. Zatímco nedostatky podpory bezdrátového síťování v Linuxu byly identifikovány a pochopeny, bylo zřejmé, že mohou být nejen vyřešeny, ale že některá řešení jsou už velmi vyspělá. Půjde-li vše podle plánu, tak den, kdy bude bezdrátové síťování v Linuxu "prostě fungovat", není daleko.

       

Komentáře

[xvasek]

Perfektní článek. Docela bych řekl, že to úroveň zpravodajství z Kernel Traffic minimálně dosahuje, spíš ale nechává někde za sebou. Díky.

[Zdeněk Štěpánek]

Moc prima clanek, uz se tesim na "bezkonfigurační mesh síťování".

Zdenek

[blesk]

Jen poznamecka, Spanning Tree neni napnuty strom, ale kostra ... Jinak skvely clanecek, jen tak dale :)

[Robert Krátký]

Je to tam jen pro ty, kteří to možná kdy používali. Viz e-archiv Jiřího Peterky: Spanning Tree (konec třetího odstavce odspodu).

[Jan Grmela]

Taky jsem si říkal, že by se s tím bezdrátem v Linuxu mohlo něco udělat...když vidím, jaká je pohodlnost konfigurace např. oproti Win, tak z toho moc radost nemám.