abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 1
včera 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 26
včera 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 8
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 14
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 25
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 15
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 5
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 774 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: viac access pointov s rovnakymi ESSID

2.10.2008 18:20 xsustek | skóre: 6
viac access pointov s rovnakymi ESSID
Přečteno: 571×
Chcem sa opytat, ako sa sprava wireless client, resp. pocitat, ktory sa pripaja do wireless siete, ked ma k dispozicii viacero AP s rovnakymi ESSID (nazvami siete). Zaujimalo by ma, ci pri scanovani okolia vidi vsetky alebo len jeden s najsilnejsim signalom. A tiez, ze ak si klient pamata heslo pre jeden AP s nejakou ESSID a je mu dostupny iny AP s rovnakym ESSID, ci sa skusi prihlasit s tymto heslom, alebo medzi nimi rozlisuje podla MAC adresy a rozozna, ze dane heslo nie je pre ten AP.

Dik.

Odpovědi

Jakub Lucký avatar 2.10.2008 19:51 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
To dost pochybuju... Orientace u AP se stejným ESSID probíhá podle channel, na kterém jednotlivá AP běží...

Ale nějak nevím, co myslíte tím "wireless client"
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
2.10.2008 22:09 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
wireless client som myslel pocitac, ktory sa pripaja k access pointu. Napr. notebook s windowsami, ktory zobrazi dostupne ap.

Ja tiez neviem presne o co pochybujete. Myslite tym, ze ich teda ten pocitac vidi vsetky, nezaleziac na tom ci maju rovnake essid?
6.10.2008 13:30 Jirka | skóre: 36
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Ano, vidí je všechny. Sítě mohou mít stejné ESSID, nebo dokonce žádné, mohou také vysílat na stejném kanálu (i když je to blbost). Podstatné je zřejmě jen BSSID (MAC AP), které by mělo být z výroby jedinečné. Pokud ho někdo změní, tak si následky nese sám.
6.10.2008 13:31 Jirka | skóre: 36
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Sakra, měl jsem si nejdříve dočíst celou diskuzi. Omlouvám se.
2.10.2008 21:22 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
ci pri scanovani okolia vidi vsetky alebo len jeden s najsilnejsim signalom
Když AP vysílá beacon rámce, tak se o něm klient dozví tak jako tak.

Pokud klient pošle probe dotaz, tak se dozví jen o těch AP, které mu odpoví.

Klient samozřejmě může pasivně sledovat rádiový provoz a může se tak dozvědět i o strojích, který se s ním bavit nechtějí.
rozlisuje podla MAC adresy
V principu asociace na AP se řídí podle BSSID, což není nic jiného než MAC adresa AP. Takže ano, rozlišuje.

Otázka ale je, jak je udělaný stavový automat uvnitř klienta. Obvykle se pro podpoření mobility považují všechny AP se stejným ESSID za jednu síť a klient si automaticky vybírá AP s nejlepším signálem. Samozřejmě při přechodu se musí od starého AP odhlásit a přihlásit se k novému.

Např. iwconfig z wireless-tools má parametr ap, kterým si můžete vynutit konkrétní AP podle jeho MAC adresy.
2.10.2008 22:28 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Dakujem za odpoved.

Mohli by ste mi prosim este strucne vysvetlit co su beacon ramce a probe dotazy, pripadne ako sa s nimi pracuje v linuxe.

Moj problem je asi takyto:

Chcel by som urobit nejaku jednoduchu redistribuciu klientov(klient = pocitac, ktory sa pripaja do siete) vo wireless sieti, ktora sa sklada s viacerych ap. (Predpokladam, ze v takychto sietach su ESSID nastavuje rovnake). Otazkou je ci by stacilo len nastavit ap napr. tak ze by klienta odpojilo a zakazalomu pristup a klient by sa sam prepojil na najblizsi ap. Alebo je to mozne len s podporou na klientovej strane. Toto su len pociatocne uvahy.
3.10.2008 00:00 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Seznam různých druhů rámců v 802.11 se stručným popisem lze nalézt v článku Understanding 802.11 Frame Types.

Beacon rámce jsou automatická opakovaná ohlášení přítomnosti AP. Z nich je obvykle vytvořen seznam dostupných AP, který vidíte v ovládacím programu na klientovi.

Probe rámec je dotaz klienta konkrétního AP na jeho schopnosti (rychlost apod.). AP by na takový dotaz měl klientovi odpovědět. Tento rámec se používá, když klient chce vědět podrobnosti, které nejsou v beacon rámci uvedeny. Rovněž se používá, když AP samo beacon rámce neposílá (někteří správci jej vypínají, protože se mylně domívají, že tím jejich síť nikdo nenajde).

Ohledně mobility, kterou požadujete, tak tam existuje celkem dobrá podpora jak ve standardu, tak i v profesionálních access pointech.

Běžný scénář je ten, že klient si sám vybere, ke komu se připojí. Když pak přechází, tak se od sítě neodpojuje (protože by vznikla prodleva, ve které by nebyl nepřipojený, i když by byl v dosahu obou AP), ale pošle na nové AP požadavek na reasociaci a nové AP samo jinou cestou (třeba po drátě) se domluví s původním AP, že klienta přebírá (tato činnost může i zahrnovat přeposlání neodeslaných paketů z bufferu starého AP na AP nové).

Váš způsob vynucení přechodu klienta by měl teoreticky fungovat. Prakticky to závisí opět na konkrétním klientovi, jak je naprogramovaný.
3.10.2008 17:28 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Chcel by som sa este opytat na ten scenar, ktory opisujete.

Ako by sa tato reasociacia robila manualne v Linuxe, (bud prikazmi, skriptom alebo nejakymi systemovymi volaniami v C)? Mohli by ste mi ju strucne opisat? Nikdy som o takejto reasociaci nepocul, ze by bezne APointy (nie drahe masinky za tisice dolarov) podporovali prehadzovanie klientov a nejako sa o tom este dohovarali.

Nieco taketo by som v podstate chcel urobit (avsak len nejaky jednoduchy prototyp). Narazil som vsak na tieto problemy.

1.) Ak by sa AP neboli schopne dohovarat o prehadzovani klientov, co sa domnievam, ze nie su, tak by to prepnutie bolo mozne len v tedy, ak klient nema otvorene ziadne TCP spojenia ( v lepsom pripade neprima, ani nevysliela na UDP portoch. Ale tie TPC su prvorade. Inak by mu po prepnuti vsetky spojenia padli. Co je dost velke obmedzenie.

2.) Takisto je tu problem s pridelenou adresou od dhcp servra. Domnievam sa, ze v sietach s viacerimy AP byva vycleneny segment adries a jednotlive dhcp servery v access pointoch prideluju casti tejto skaly. Napriklad: Majme siet 155.155.0.0, kde pre wireless siete je prideleny segment 155.155.48.0/24 Prvy AP prideluje od 155.155.48.1 po 155.155.48.20 a druhy 155.155.48.21 po 155.155.48.40 atd.( dufam, ze tie pocty su spravne :). To znamena, ze po prepnuti klienta na ine AP dostene movu adresu z inej skaly a preposielanie neodoslanych paketov by uz teraz bola dost zlozita uloha.

Moj model bol taky, ze sa klient prepne len v pripade, ze nema otvorene TCP spojenia a dostane novu adresu v sieti.

Dakujem vopred za postrehy

3.10.2008 18:37 Ivan
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
ad 2) Neni snazsi pouzivat DHCP realy, a dhcp dotazy z cive AP forvardovat a jeden DHCP server? Pak by nebyl problem prechazet mezi AP a neztratit pri tom otevrena TCP spojeni.
3.10.2008 20:24 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Mozes mi trochu opisat ako ten realy (asi myslis relay), to vobec nepoznam. Ale aj keby to bolo mozne, ako by si nakonfiguroval router v tej podstieti. On dostane paket pre nejaku adressu napr. 155.155.48.5 a nebude vediet ktoremu ap to ma preposlat, lebo by nevedel na ktorom je ten klient pripojeny.

Ja si myslim (ked to je zle opravte ma), ze prave tym, ze ap davaju konkretne skaly adries, moze byt v routery napisane, ze pre adresy od 155.155.48.1 az 155.155.48.20 posli na 1.ap, od 155.155.48.21 - 155.155.48.40 na druhe ap. Keby sa museli menit tabulky kvoli kazdemu prepnutemu klientovi, to by bolo este horsie.
4.10.2008 17:11 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Problém se řeší tak, že se zcela obejde. Jednotlivé AP fungují na linkové vrstvě, takže celá síť se jeví jako jediný ethernetový segment, jako by všude byly switche. Směrování pak probíhá rovněž na druhé vrstvě podle MAC addres.

Samozřejmě, že toto řešení se hodí jen pro menší sítě jediného provozovatele jako je třeba areál školy. Snad by jej šlo i nasadit třeba při zasíťování dopravního koridoru (u nás SCI-FI).

U rozlehlých sítí bych spíše sázel na mobiliní IP.

Ohledně programování reasociace:

Na klientovi netřeba nic dělat, tam to obvykle dělá firmware síťovky, u novějších karet pak ovladač v jádře.

Na AP umí ovladače hlásit, kdy se jaký klient připojil nebo odpojil. Např. ovladač hostap pro (dnes již historické) karty ZCOM XI-626 tyto informace vypisuje jak do jaderného logu, tak je lze najít v souborovém systému proc. Rovněž kvůli WPA a autentizaci přes Radius existuje rozhraní s uživatelským prostorem, kdy běží proces hostapd, který umí tyto informace v reálném čase získávat z karty a dále zpracovávat a následně kartě sdělit, zda má klienta přijmout nebo odmítnout.

Domnívám se, že dnešní linux již má nějaké standardizované API (asi přes NETLINK sockety), jak tyto informace sdělovat do uživatelského prostředí.

Pak stačí démon, který bude komunikovat s ostatními AP a bude umět zařídit deasociaci na starém AP, když se u něj objeví nový klient.

Nebo, a to mi přijde jednodušší, žádná složitá komunikace nebude. Prostě nové AP vyšle broadcastový rámec se zrojovou adresou nového klienta. Tato zpráva se roznese po celé síti, dojde i ke starému AP, kde démon bude sledovat bridgovou tabulku a když se mu tam objeví místní MAC na drátové straně, tak ví že klient je pryč.

Co se týče přeposílání nabufferovaných rámců ze starých AP, tak tam si nejsem jistý, jestli to je v Linuxu možné. Ale po drobnější úpravě to asi půjde, protože jak bridgovaní tak i failover trunky už Linux umí. V podstatě se z bufferu vytahají rámce směrované odešlému klientovi a znovu se pošlou do bridge. Ten už jej odešle zpět na nové AP.
6.10.2008 10:47 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
V prvom rade by som vam chcel podakovat za odpovede, su velmi prinosne. Ak by vam to nevadilo, opytal by som sa este par otazok.

Jednotlivé AP fungují na linkové vrstvě, takže celá síť se jeví jako jediný ethernetový segment, jako by všude byly switche. Směrování pak probíhá rovněž na druhé vrstvě podle MAC addres.

Toto je automaticky mechanizmus? Znamena to, ze ked zapojim 3 AP do jednej siete/segmentu. Sami si preposielaju ramce pre inych klientov. Alebo sa to routovanie musi nastavovat? Inymi slovami, ked router siete dostane paket pre nejakeho klienta posle ho na hociktory AP, kt. ho preposle pripadne na ine AP?Poznate nejaky zdroj kde je tento mechanizmus opisany?

Este k tej reasociacii.

Když pak přechází, tak se od sítě neodpojuje (protože by vznikla prodleva, ve které by nebyl nepřipojený, i když by byl v dosahu obou AP), ale pošle na nové AP požadavek na reasociaci

Mohli by ste mi prosim opisat tu reasociaciu krokovo? Je tam nejaka podpora v standarde? Moja predstava je : 1. Klient je pripojeny k jendemu ap 2. Klient scanuje okolie 3. Klient sa prepaja na druhe ap. co pozostava z krokov: odpojit, pripojit k novemu

6.10.2008 13:52 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Jednotlivé AP fungují na linkové vrstvě, takže celá síť se jeví jako jediný ethernetový segment, jako by všude byly switche. Směrování pak probíhá rovněž na druhé vrstvě podle MAC addres.

Toto je automaticky mechanizmus? Znamena to, ze ked zapojim 3 AP do jednej siete/segmentu. Sami si preposielaju ramce pre inych klientov. Alebo sa to routovanie musi nastavovat? Inymi slovami, ked router siete dostane paket pre nejakeho klienta posle ho na hociktory AP, kt. ho preposle pripadne na ine AP?Poznate nejaky zdroj kde je tento mechanizmus opisany?

Ano, je automatický mechanismus do té míry, že není třeba nastavovat nějaká pravidla pro směrování.

Jediné, co je třeba udělat, je zapnout bridge mezi rádiovým a drátovým rozhraním v AP.

I když 802.11 (WiFi) se snaží být podobný 802.3 (kabelový Ethernet), je zde jistý rozdíl ve struktuře rámců. Tohle musí ovladač rádia vzít na vědomí a umět mezi těmito dvěma formáty převádět. Je to vidět např. v programu tcpdump, který, když se pustí nad 802.11 rozhraním, tak o tom informuje a vypisuje 802.11 rámce se všemi čtyřmi MAC adresami (zdrojová a cílová 802 rámce, zdrojová a cílová 802.11 rádia).

Jednotlivé uzly se směrovací pravidla učí za běhu podle toho, kudy chodí rámce pocházející ze stroje s danou MAC adresou.

Příklad: Router se rozhodne odeslat packet do segmentu s AP, přes ARP/NDP zjistí MAC adresu stroje, který má danou IP adresu, a odešle rámec. Přijme jej switch, zkusí najít cílovou adresu ve své tabulce adresa−port. Když ji tam najde, přepošle rámec daným portem na jediné AP. Když ji nenajde, rozešle stejný rámec skrze všechny porty (až na ten, kudy rámec přišel). Rámec přijme AP a udělá úplně stejnou věc jako switch. Pokud je k němu daný klient připojen, odešle mu rámec. Když není, tak rámec zahodí (předpokládejme, že AP má jen dvě rozhraní: jedno 802.3 a jedno 802.11).

Příklad přeposílání rámce odešlému klientu: výše popsaným způsobem doputuje rámec na AP, avšak mezi tím se klient naasociaval na jiné nové AP. Staré AP to zatím neví, rezervuje si kanál pro sebe a odešle rámec a čeká na potvrzení příjetí klientem. Potvrzení nedostane, protože klient je pryč. Zkouší to dokud nevyprší limit opakovaných pokusů na doručení. (Pokud potvrzování přijetí není implementováno – je to volitelná součást protokolu 802.11, budou rámce odvysílány do éteru, aniž by je někdo zpracoval.) Mezitím si AP uvědomí, že klient je dosažitelný přes 802.3 port (ať už příkazem z jiného AP nebo sledováním bridgovací tabulky adresa-port). Nyní vyjme rámce z odesílacího bufferu 802.11 rozhraní, vymaže si klienta ze seznamu asociovaných klientů, rovněž odmaže záznam z bridgovací tabulky ukazující na tento 802.11 port a nakonec vyjmuté rámce pošle do bridgovací kódu. Ten buďto záznam nemá, a tak rámce odešle na obě strany (přičemž na rádiu budou zahozeny, protože tam už není klient naasociván), nebo záznam už má ukazující na drátové rozhraní, a tak budou rámce odeslány jenom tam. Rámce opět přijme switch a podle dříve popsaného mechanismu je přepošle jinam.

Při pečlivém průzkumu lze najít místa, kdy se rámce prostě ztratí. Ale to je již riziko Ethernetu, protože ten obecně nezaručuje doručení.

6.10.2008 19:20 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Mezitím si AP uvědomí, že klient je dosažitelný přes 802.3 port (ať už příkazem z jiného AP nebo sledováním bridgovací tabulky adresa-port). Nyní vyjme rámce z odesílacího bufferu 802.11 rozhraní, vymaže si klienta ze seznamu asociovaných klientů, rovněž odmaže záznam z bridgovací tabulky ukazující na tento 802.11 port a nakonec vyjmuté rámce pošle do bridgovací kódu. Ten buďto záznam nemá, a tak rámce odešle na obě strany (přičemž na rádiu budou zahozeny, protože tam už není klient naasociván), nebo záznam už má ukazující na drátové rozhraní, a tak budou rámce odeslány jenom tam.

Toto je kompletne automaticky mechanizmus? Asi su tam nejake limity ohladne buffera a takisto casu. V pripade, ze sa klient uspesne reasocioval s inym AP, kolko casu zabere, pokym sa to prve ap od ktoreho sa disasocioval dozvie o nom, aby mu tie ramce z bufferu mohol poslat? Nebol by tomu dobre nejak pomoct? Napr. tak, ze by klient po reasociaci, pingol na prve ap aby sa zmenili ARP tabulky. V sieti, proste aby dal o sebe nejako vediet.

Rozmyslal som o bezpecnosti v takychto sietach? Nastavit rovnake hesla na vsetky ap by asi nebol najstastnejsi napad. Napadol ma radius server, ale neviem kolko autentizacia zabere casu.
6.10.2008 20:18 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Toto je kompletne automaticky mechanizmus?

Jak vidíte, nic nikde nemusíte konfigurovat, sít si sama uvědomí, že klient je jinde a začne rámce směrovat na správné místo.

Asi su tam nejake limity ohladne buffera a takisto casu.

Samožejmě, buffer není neomezený. Když se zaplní, tak se nové pakety budou zahazovat. Rovněž existují časové limity na asociaci klienta, který se dlouho nezval. Tohle ale všechno jsou lokální záležitosti, které nemění princip směrování v síti. Mají pouze vliv na výkonnost sítě.

V pripade, ze sa klient uspesne reasocioval s inym AP, kolko casu zabere, pokym sa to prve ap od ktoreho sa disasocioval dozvie o nom, aby mu tie ramce z bufferu mohol poslat?

To záleží, jak je to udělané. V nejkratším prípadě je to doba nutná na dopravení jednoho rámce z nového AP na staré přes drátové rozhraní.

Nebol by tomu dobre nejak pomoct? Napr. tak, ze by klient po reasociaci, pingol na prve ap aby sa zmenili ARP tabulky. V sieti, proste aby dal o sebe nejako vediet.

Jistě, že je dobrý nápad. Nicméně to vyžaduje spolupráci od klienta, kterou standard nepožaduje. Proto je možná vhodnější (i když ne tak účinné) nechat udělat to nové AP. Stačí odeslat rámec se zdrojovou adresou klienta a všesmerovou cílovou adresou, čímž se aktualizují tabulky v celé síti.

Rozmyslal som o bezpecnosti v takychto sietach? Nastavit rovnake hesla na vsetky ap by asi nebol najstastnejsi napad. Napadol ma radius server, ale neviem kolko autentizacia zabere casu.

Proč by to bylo špatné. V okamžiku, kdy potřebujete mobilní klienty a celá síť je propojená na linkové vrstvě, tak nemá smysl, aby se některá AP chovala jinak.

Jinak radius se na tohle obvykle používá. A ano, 802.1x autentizace je pomalá. Proto se obvykle celá autentizace provádí jen při první asociaci a při reasociaci si AP stáhne klíče z autentizačního centra.

Po pravdě řečeno se zde používají tzv. lehká AP, která řeší jen věci přímo související s rádiovým přenosem a zbytek včetně šifrování se deleguje do centra přes drátovou síť.

Navíc výměnu klíčů lze urychlit spekulativním rozkopírováním klíčů mezi sousední AP, takže když klient přechází, tak už je vše připraveno a stačí případně provést standardní WPA rekeying (tedy dojednání nových klíčů za pomoci těch starých).

6.10.2008 14:03 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Mohli by ste mi prosim opisat tu reasociaciu krokovo?

Může to být tak, jak to popisujete (třeba CISCO si tak zjednodušuje život). Nicméně standard definuje služební rámec pro reasociaci, který zasílá klient novému AP, přičemž starému AP nic neoznamuje (např. rámcem pro disociaci). Je na AP, aby se mezi sebou o tom domluvila.

6.10.2008 15:15 iwik
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Pozrite si protokol IAPP. http://www.cs.umd.edu/~mhshin/iapp/
6.10.2008 10:58 xsustek | skóre: 6
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID
Este tato vec

Např. ovladač hostap pro (dnes již historické) karty ZCOM XI-626 tyto informace vypisuje jak do jaderného logu, tak je lze najít v souborovém systému proc

Neviete konktetny subor v proc, pre hostap?
6.10.2008 14:12 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: viac access pointov s rovnakymi ESSID

V adresáři /proc/net/hostap/NÁZEV_ROZHRANÍ jsou asociovaní klienti reprezentováni jako soubory, jejichž jméno je rovno jejich MAC adrese.

V logu pak připojení vypadí takto:

wifi0: 00:13:ce:61:b9:63 auth_cb - alg=0 trans#=2 status=0 - STA authenticated
wifi0: 00:13:ce:61:b9:63 assoc_cb - STA associated

a odpojení pro nečinnost klienta takto:

wifi0: disassociation: 00:13:ce:61:b9:63 len=2, reason_code=1
wifi0: STA 00:13:ce:61:b9:63 did not ACK activity poll frame
wifi0: sending disassociation info to STA 00:13:ce:61:b9:63(last=42782363, jiffies=42857613)
wifi0: sending deauthentication info to STA 00:13:ce:61:b9:63(last=42782363, jiffies=42857863)
wifi0: Could not find STA 00:13:ce:61:b9:63 for this TX error (@42857865)

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.