Wifi Roaming

Hálózati eszközök

Sziasztok.

Adott egy wifi hálózat, amely így épül fel.

NET --vezetékes kapcsolat--> AP (rajta 5gh p2p és 2.4 körsugárzók) ...(5ghz link)...> Station (rajta a kliens 5ghz antenna és 2.4-es körsugárzó)

Tehát, a lényeg vegyük úgy, hogy két 2.4 -es ap van, amit össze vannak kötve (mindenhol bridge mód van) 5ghz-es gerinccel (most két ilyen van, de később lesz több is). Azt kellene megoldani, hogy aki vándorol a két ap között úgy tudjon átkapcsolódni a másik ap-ra, hogy ne szakadjon meg a kapcsolata.

Mindenhol MikroTik-et használunk. Olvastam sok mindent, de jó lenne olyannak a véleménye, aki biztos benne, hogy hogyan kell, és hogyan működik is megfelelően. A legtöbb helyen ahol wds-t emlegetnek, ott nincs külön gerinc, hanem csak két ap van, ez nekünk nem jó, mert a két ap közvetlenül nem látja egymást olyan minőségben, mint az 5ghz-s gerinc...

Köszönöm a tippeket/segítségeket!

( Balu007 | 2014. 08. 04., h – 10:06 )

A roaming a klienstol fugg.

Esetleg ha EAP-vel autentikaltatsz es az AP-jaid ismerik, akkor meg lehet osztani a bejelentkezo infokat es gyorsabb lesz az autentikacio.

A kliensen kellene beallitani, hogy hany dB alatt nezzen szet ujra, hogy van-e erosebb jel; es akkor atcsatlakozik

Az auth mac szűréssel (felesleges a titkosítás, mert olyan a felhasználás) lesz megoldva, pont a gyorsaság miatt. Kliens oldalon megnézem van-e ilyen lehetőség, de a mikrotikban tudom, hogy van olyan, hogy vmekkora jel alatt ledobja. De nekem vmi wds féleség kellene, tehát nem azt szeretném, hogy a kliens keressen másik hálót, hanem, hogy ez autómatikusan történjen

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Bár mélyebben még soha nem foglalkoztam wifi roaming-al, de már itt is olyan sokszor előkerült a téma és jó megoldást még nem láttam rá.
Most komolyan még a legújabb wifi szabványokban sincs implementálva a lehetősége, hogy a hálózat mondja meg a kliensnek, hogy "Te most szépen átmászol Arra az AP-re, mert neked az jobb, itt meg kell másoknak a kapacitás!"?

Nalunk ez a rendszer van, kollegam egyszer probalta meg beallitani rajta a roamingot, aminek az lett az eredmenye, hogy az iroda mindharom AP-je azonos channelre kerult, a sok kliens miatt ez meg igy kvazi hasznalhatatlan lett, tobbek kozott azert van tobb AP, mert sok a kliens.

Ennek tenyleg igy kell mukodnie? A roaminghoz azonos channel-t hasznalo AP-k kellenek?

Sajnos a technikai oldala ertheto, ahogy Answ irja. A klienseknek igy semmit nem kell csinalni, vagyis pont ugyanazt kell tudnia egy kliensnek amit 10 eve is uodtt, csatlakozni egy darab AP-hez egy csatornan. Eszre se fogja venni, hogy mar nem ugyanazon az AP-n van. De emiatt ebben a formaban ez nalunk is hasznalhatatlan lett.

"A roaming a klienstől függ", írod. Szabvány szerint igen. Márpedig a kliensben gyenge a driver, plusz nincs benne spektrum analízis, így nemigen látja, h mi történne, ha máshova csatlakozna. Ergo sose fog normálisan roamingolni, és legfeljebb az első csatlakozásnál fog a legerősebb AP-ra felcsattanni (ami bőven lehet, h nem a legjobb hiszen mindenki oda megy fel, amikor bejön az épületbe, a többi AP meg ugyan gyengébb jelű, de üresen áll). "Sticky client" probléma.

Az Aruba ClientMatch technológiája pont ezt kezeli. Az aktuális AP-ról nyilván minden valamirevaló gyártó látja, hogy az élő kapcsolat milyen minőségű (adáserősség, jel-zaj arány), de ez a rendszer a környező AP-kon is látja spektrum analízis segítségével, hogy milyenek lennének az értékek, ha inkább oda csatlakozna a kliens. Így a terhelési és rádiófrekvenciás adatok segítségével megalapozott döntést tud hozni arról, hogy jó-e, ha a kliens marad, vagy inkább át kell roamingoltatni. Ha az utóbbi a döntés, akkor akár channel switch announcementtel szakadásmentesen lehet megtenni. Hasonló van egyébként a mobilhálózatoknál.

(az Aruba disztribútoránál dolgozom)

( informer v | 2014. 08. 04., h – 11:20 )

Szervusz,
HWMP+ a te "barátod". Ez egy spec Mikrotik protokoll. Külön főmenüben találod MESH néven.
Alapban úgy indulj el, hogy pl adott 3 router A1,A2,A3.
A1 -en beállítod ap mode-ban secrettel ahogy szoktad, de:
A wlan interface-t kiveszed a bride-ből. Készítesz neki egy MESH "bridge"-t amihez hozzáadod wifi port-ként. A MESH-en kipipálod a mesh-portal-t de csak az A1-en. A többin is így teszel, ugyanaz a csatorna ugyanaz az ESSID, plusz a wds fülön a wds-mesh-et választod ki és a mesh "bridge"-be teszed a leendő wds eszközöket.

A HWMP+ protokoll majd gondoskodik a "vándorló" mac address kezeléséről. Az egész egy bridget képez, így a gerincet akár beteheted ide is, vagy külön is kezelheted de akkor minden AP mesh portal lesz, vagy EoIP tunellezel szóval lehet variálni.
http://forum.mikrotik.com/viewtopic.php?f=7&t=63263
http://wiki.mikrotik.com/wiki/Wireless_WDS_Mesh
http://wiki.mikrotik.com/wiki/Mesh_wds

Szerintem ennek semmi koze a zero handoff-hoz, csak a gerinc halozat lesz mas. A kliens ettol meg csak egy ESSID alatt fogja latni a halozatot, de BSSID-bol tobb lesz. Tudtommal olcso eszkozokbol csak az A'rpi altal emlitett Unifi ismeri a zero handoff-ot (es AC-n az sem meg).

A nagy kulonbseg, hogy zero handoff eseten a kliens szempontjabol nincs handover, igy kimaradas sem. Raadasul az elcseszett wifi szabvany miatt sincsen az, hogy rajta marad egy meg elerheto AP-n gyenge jelerosseggel, ahelyett hogy valtana mar a szerencsetlen kliens az erosebb AP-re. Az hogy forced roamingot kihagytak a szabvanybol megbocsajthatatlan (es ezen a 802.11r sem segit, csak a kimaradason)

Először is, Köszönöm mindenkinek a hozzászólást!

Ezt a wds mesh-t néztem én is, de csak olyan megoldásokat találtam, hogy nincs külön gerinc. Simán a wds nekem nem jó a teljesítmény miatt sem és a lefedettség miatt sem. Vmi ilyesmi megoldás kellene, annyi különbséggel, hogy a gerincet használja az ap-k közötti kommunikációhoz.

Egyébként, ahogy elnézem a hozzászólásokat nem biztos, hogy ez megfelelően fog működni, lehet, hogy inkább több ssid kellene és különböző csatornákon maradjanak az ap-k, és a klienseknek mondom meg, hogy figyeljék mi a helyzet, és újracsaatlakozzanak adott esetben. A kliensek egyébként openwrt-t futtatnak, így ott talán ez megoldható (hogy hogyan annak még utána kell mennem, esetleg vmi ötlet, valaki használ ilyet?).

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

re, a mesh interface-en amikor felveszed a port-okat akkor tudod megadni, hogy milyen típusú az az interface, és mennyi a path cost-ja. Azaz pl kicsi (10-es) legyen az ethernet és nagyobb, esetleg 20-as legyen a gerinc interface. Majd a HWMP+ oda küldi a csomagot ahopl jobbak a feltételek.A gerinc interface az természetesen ne legyen benne ebben a wds-mesh -ben! A gerinc az "csak egy bridge-et alkot 5gigán mint egy utp kábel". (khm ez így randa de talán szemléletes.) Az egyes AP-ken access szabállyal pl tiltsd le azokat akik kisebb mint -80dB-vel akarnak bejönni.
Sajnos kliens szinten is kell tudni állítani a roaming képességet, hogy mikor váltson, ha sebesség kell vagy ragaszkodjon mindig a "régi ap-hoz" na ezt pl. androidban nem találtam.
Mikrotiken IMHO ez az amit jelenleg el lehet érni. Ettől sajnos a VOIP lebont(hat) vagy a kliens a másik AP-n ragad és lassú mint a dög, túl sűrű és nem kellően "sector-ált" antennáknál valóban agyonvágja a collision.
(ezeket korrektül az Aruba vagy a Ubi tudja lekezelni bár ott is számít a telepítés az elhelyezés!)

( lcseh | 2014. 08. 04., h – 13:09 )

Az a gond, hogy az AP-k teljesítményével senki sem foglalkozik. Ha normális roaming kell, akkor az egymás melletti AP-k teljesítményét szabályozni kell. A kliens az AP-k frame-jeiből mérik az RSSI-t és ez alapján döntenek roamingról. Ha a jelszintek nincsenek jól beállítva, akkor kampeca.

1. Normális sit-survey (felmérés)
2. Az AP-k helyének ez alapján történő minél pontosabb meghatározása.
3. Nem a minél kevesebb AP - annál jobb elv követése
4. teljesítmények beállítása.

Rengeteg dokumentáció található a neten, a survey-t viszont jól csak drága szoftverekkel (Ekahau, Airmagnet-Fluke) lehet majdnem tökéletesen felmérni. Nagyon jó közelítést adnak a kézi bejárások, de hogy hova kerüljön az AP, milyen zavarjelekkel kell számolni ( ami adott esetben meg is öli a wifi jelét) csak egy jó szoftverrel és spektrumanalizátorral lehet megmondani.
A jó hír az, hogy ezeket adott esetben bérbe is lehet venni hardverrel együtt és akkor nem kell kiadni 10-20 ezer dollárt egy telepítésre. Aki ezzel foglalkozik, előbb-utóbb rájön, hogy a precíz dokumentáláshoz, felméréshez elemgedhetetlen. Sajnos én is csak vágyom egy ilyenre. Az Ekahau-t ismerem, nagyon sok AP gyártó benne van, Cisco, Zyxel, Dlink, stb. Antennakarakterisztikától kezdve mindent tudnak, ismernek.

Igen, ezt próbáltuk így csinálni, de mint írtad, nincsenek erre profi eszközeink, így csak a rendelkezésre állókat tudtuk használni. Az ap-k elhelyezése szerintem elég jól sikerült, nincs sem túl sok, sem túl kevés. A teljesítmény, hát ezzel még játszani kell, főleg, ha mest-t használunk, és azonos frekire kerülnek...

Egyébként, elég gáz, hogy szabvány szinten ez nincs konkrétan meghatározva :(...

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

IMHO az 5GHZ-es link, (amennyiben a felállás 2,4GHz AP---5GHz WDS<<<<>>>>5GHz WDS---2,4GHz AP) ugyanúgy viselkedik, mintha switchel lenne összekötve. Vegyétek vissza a teljesítményt 75-50%-ra és próbáljátok ki úgy. A firmwareeket frissíteni kell, gondolom ez megvolt!?, és ha nem akkor valami rendes AP kell, pl. ZyXEL NWA5123NI, ez is kétrádiós, ugyanebben a felállásban menni fog.

( szollosiimre | 2014. 08. 05., k – 13:27 )

A mesh és a roaming két történet. A mesh a hálózatot terjeszti vezetéknélküli uplink segítségével. A roaming a kliens mozgását jelöli, miközben egyik BaseStation-ről a másikra vándorol.

El kell különíteni egymástól a különböző roaming megoldásokat is, mert ez nélkül nem lehet megfelelő módon tárgyalni a kérdést:

Az ubiquiti ezt a zero-handoff segítségével éri el, aminek valóban azonos frekvencia az előfeltétel.

https://community.ubnt.com/t5/UniFi-Frequently-Asked-Questions/UniFi-Wh…

Kontrolleres, vagy egyéb virtual kontrolleres eszközök esetén szintén szabvány alapon rssi és egyéb paraméterek gyűjtésével a kontroller kalkulálja ki a megfelelő mozgást. Ez természetesen az inteligencia helyétől is függ.

Gyártók szerint megfelelő 802.11valami taggal jelölt szabványok segítségével.

Kiegészített kialakítás, hogy maga a kliens is támogathat különböző megoldásokat, mind pld cisco ccx extension.