CAPsMAN a použití u VoIP

[Petr S.]

Ahoj,

řeším teď zasíťování jednoho domova důchodců - je to celkem velká budova a vymysleli jsme, že by na jedno patro byli čtyři AP. Přemýšleli jsme o RB951Ui, kde jsem rozjel CAPsMANa a nastavil, aby AP vykopávalo klienty při snížení signálu pod -80dB. Při přechází mezi AP to celkem funguje a i když mezi nimi chodím například s telefonem s Viberem. Ale když jsme zkusili ještě telefonování přes SIP, tak to začalo zlobit - jakmile došlo k přepojení na jiné AP, signál byl sice maximální, ale už nedošlo k opětovnému navázání komunikace.

Řešili jste něco takového taky? VoIP je pro tohle řešení hlavním požadavkem, takže i pokud byste měli návrh na jiná zařízení, kde roaming funguje líp, sem s nimi Akorát to nechápu, když přejdu na jiné AP, signál je maximální, ale VoIP (SIP) nefunguje...

[okoun]

použij ubnt unifi, tam to funguje dobře, bohužel mikrotik toto zatím nevyřešil.

[Petr S.]

Máš to vyzkoušené, že s VoIP to funguje? Kolegové to dřív už nějak zkoušeli, ale prý taky nic moc. Ale třeba to mohli mít špatně nastavený, nevím... Je ke správnýmu použití potřeba controller?

[Peyrak]

pokud chceš ten jejich roaming tak je controler nutnej

[Rosak]

pokud chceš ten jejich roaming tak je controler nutnej

Mohl byste, prosím vysvětlit v čem roamingu napomáhá kontrolér? Všude se o tom lidé přou, ale nikdo nevysvětlí jak to funguje. Předem díky za Váš čas.

[the.max]

Moje zkušenost c CAPsMANem v jedné restauraci je taky rozporuplná. Na běžné prohlížení Internetu je to OK, ale protože to neumí rychlé předávání klientů, tak to pro VoIP není zatím moc použitelné. Já tedy neřešil VoIP, ale RDP. V restauraci servírky používají tablety pro objednávání jídel a nosí malé termotiskárny pro tisk účtenek. Problém je podobný, když dojde k přepojení na jiné AP, tak se prostě RDP rozpojí, je nutné RDP klienta zavřít, znovu spustit a přihlásit se. Jsou dny, kdy to i relativně normálně funguje bez nutnosti ukončení, spuštění a přihlášení, ale moc jich není. Bohužel se mi nepodařilo vypozorovat okolnosti, za kterých to 'funguje' oproti dnům, kdy se to pořád musí vypínat a zapínat.

Zkoušel jsem CAPsMANa zrušit a dát APčka do WDS+RSTP, což bylo mnohem horší, než s CAPsMANem. Zkoušel jsem i MESH, ale výsledek byl pořád stejný.

Původně tam bylo Unify, ale bylo jich málo, navíc byl vznesen požadavek, aby v restauraci fungoval i Internet pro hosty. Z firmy, která spravuje ten platební systém mi bylo důrazně sděleno, že i když Unify umí dvě SSID, tak že prostě i tam to druhé SSID pro hosty nenastaví. Z toho důvodu jsem tam dal Mikrotiky, kde jsem přez CAPsMANa docílit stavu, kdy budu mít jedno APčko v místnosti (protože tam jsou více než metrové stěny, dům je starý několik set let), na kterém budou dvě SSID, jedno pro hosty, druhé pro tablety obsluhy .

Aktuální stav je takový, že tam zůstanou Mikrotiky s Internetem pro hosty a vedle budou na jiném kanále ještě Unify pro tablety.

V 1. a 2. patře, kde jsou nad restaurací pokoje hotelu je na chodbách také několik mikrotiků na CAPsMANu pro Internet, proti tomu není jediná vítka. Stejně tak, pro stejného provozovatele, je další síť s CAPsMANem na ubytovně z kontejnerových stavebních buňek pro stavební dělníky. Tam také není proti funkčnosti jediná vítka. Ale na pokojích ani na ubytovně se nepoužívají VoIP telefony, ani tablety s RDP.

A ještě poznámka k servírkám a tabletům. Když jsem sledoval log a pohyb servírek, vypozoroval jsem následující chování:
Servírka byla v jedné místnosti, tablet připojený na AP v této místnosti (např. u výdejního okna kuchyně). Servírka vzala jídlo a nesla ho zákazníkovi na stůl. Každý asi ví, že šerǘírky se pohybují relativně rychle, zejména v době obědů. Takže Odešla z místnosti a přez další dvě místnosti šla do čtvrté místnosti ke stolu zákazníka. Když byla servírka ve třetí mistnosti, tablet ztratil spojení s APčkem. Tablet tedy začal hledat nové AP, Servírka ale mezi tím již poloźila talíř na stůl, prošla skrz místnost do dalśí mistnosti a sbírala použité nádobí ze stolu. Tablet našel síť a začal se přihlašovat. Než se ale stihl přihlásit, servírka už zase byla u kuchyně u okýnka, takže tablet zjistil, že na dané BSSID se už nemůže přihlásit a začal tedy hledat nové AP. Servírka už ale nesla pití k jinému stolu jiného zákazníka. Rozpadlo se RDP spojení. Servírka došla ke stolu, kde zákazník chtěl platit. Tablet začal hledat signál, servírka mezi tím zavřela RDP klienta a znovu ho spustila, pokusila se přihlásit, ale zkončilo to s chybou o nedostupné síti. Tablet se úspěšně přihlásil, servírka tedy znovy vypla a zapla RDP klienta, přihlásila se a vystavila účet.
Když tam bylo Unify, tak problémy s odhlašováním a přihlašováním nebyli. Bohužel, nikdo mi před instalací mikrotiků nebyl schopen říci jak ten platební systém funguje, že běží na RDP, že firma dodávající ten to systém nepovolí ani dvě SSID na unify atd... prostě na palici.

'Roaming' jako takový podporují třeba APčka od Ruckus Wireless, Aruba, Cisco, ale tam začíná cenovka za kus na 20ti tisících bez daně. Také se objevila novinka od TP-Linku, nepamatuji si už tip, ale datasheet říká, že by to taky mohlo fungovat, controller běží na WIN, ale vyloženě o 802.11r (roaming) se tam také nepíše, cena mezi 2-3Kkč.

[czatlantis]

To jsou v Mikrotiku tak neschopní, že ani nedokážou okopírovat funkční řešení od konkurence, která to má X let?

[the.max]

Tak oni v Mikrotiku asi bohužel už nemají čas kopírovat pořádně, protože veškeré prostředky jim zabírá kopírování obecně (Groove/Bullet, NetMetal/Rocket/, cAP/Unify, DynaDish/RocketDish...)Je vůbec SXT jejich nápad, nebo to taky někde obšlehli? Nejhorší ale na tom je, že roaming na Linuxu (v open/dd/x/WRT) funguje. ROS je taky jen zmršenej Linux doplňený o klikací winbox s několika přepsanými funkcemi (minimálně Routing už není zebra/quagga) a prý, vlastními ovladači pro atheros čipsety. Ale 802.11 je pořád z linuxu, tak by tedy i ten roaming mohli implementovat. Na fóru se to taky hemží dotazy na roaming, ze začátku byli tazatelé 'odpálkováni' odpovědí, že to funguje, jen je potřeba to správně nastavit. Později se tam už objevovali i odpovědi s odkazy na WDS+RSTP a Mesh. Ve Wishlistu k 7.x je to zmiňováno několikrát a dokonce i normis už tazatele neodbývá, ale naopak mi to pripadá, že by už přemýšleli, o možné implementaci. Takže možná v ROSu 9.x by jsme se mohli třeba i dočkat

Na UBNT roaming funguje proto, protože jejih AirOS je jen ohackované WRT, které roaming umí.

...ale i přez to dám vždy přednost Routerboardu, před čímkoli od UBNT.

[Petr S.]

No, co jsem tak zjištoval tak ani Unify není na roaming moc velkej král... Nevím, jestli by přes to běhali třeba ty voipy...

[VSTK]

K tomu případu s VoIP i restaurací je třeba říct, že je-li více AP provozováno tak, že každé vysílá na jiném kanále s jiným BSSID, je pro chování roamingu do značné míry určující SW implementace na klientovi. Ta rozhoduje, jakým způsobem a jak rychle se klient připojí na jiné AP. Ze strany AP je v tomto scénáři možné dělat jen 1) vynucení deasociace na základě nejakých podmínek (slabý signál, případně v kombinaci se znalostí toho, že jiné AP má na tohoto klienta signál lepší, ale to se standardní 802.11 wireless částí nelze, pokud jsou různé kanály); 2) podpora standardních protokolů 802.11k a 802.1r - ale aby to mělo smysl, musí to podporovat i klientské zařízení (např. iPhone od 4s výše). Cisco má pro roaming např. CCKM (http://www.cisco.com/c/en/us/support/do ... .html#anc8), což má ovšem smysl jen při podpoře tohoto cisco-specific rozšíření na klientovi; Pak tu máme ještě "WPA2 Pairwise Master Key ID (PMKID) caching, or Sticky Key Caching (SKC)" - http://www.cisco.com/c/en/us/support/do ... gy-00.html

Druhý možný scénář je takový, že jsou všechny AP na stejném kanále se stejným BSSID - toto je doména dražších řešení, protože to pro skutečně efektivní fungování vyžaduje podstatně jiné řešení wireless chipsetu než standardní 802.11. Zásadní výhoda je, že klient v tomto případě roaming nijak neřeší, protože z jeho strany se celá sít tváří jako jediné AP. UBNT se o něco podobného snaží pod názvem Zero-Handoff, jak moc to funguje, nevím.

Jinak bych odkázal na starší vlákno: viewtopic.php?f=10&t=15574&p=158573#p158573

Bylo by fajn, pokud tu někdo píše "Na UBNT roaming funguje" a "WRT, které roaming umí", taky napsat co to technicky znamená - jestli to je podpora nějakého standardu, např. 802.11r/k, PMKID caching, SKC, nebo nějaký vendor-specific trik. Protože podpora 802.11r asi nepomůže v té situaci s restaurací, kde velmi pravděpodobně mobilní terminály toto nepodporují. Nicméně pokud se tam používá WPA2, tak bych to zkusil vypnout, a zabezpečení řešit jen MAC filtrem, a případně skrytím SSID. Režie ustavení WPA2 při reasociaci může být poměrně velká, a mohlo by to pomoct.

[the.max]

V restauraci jsou použity ipady (verzi nevím, ale určitě to není nic starého). Zkoušel jsem to provozovat jak na různých kanálech, tak i na stejném. Na stejném kanále to chodí o poznání lépe, klientům trvá přepojení na jiné AP o několik sekund méně.
Skryté SSID jsem zkoušel také, problém byl ten, že buď tiskárny, nebo ty iPady se prostě neuměli připojit. Vypnout WPA2 bych mohl zkusit vypnout, ale pochybuji, že by vedení hotelu schválilo použití pouze MAC filteru, jako zabezpečení.

Jinak se omlouvám, pokud jsem tu někoho zmátl tím, že jsem psal o 'roamingu' ve spojení s Unify nebo WRT, ale vždy jsem se snažil psát 'roaming (v uvozovkách) a ne roaming, čimž bych myslel konkrétně 802.11r'. Jinak jsem čerpal i z https://community.ubnt.com/t5/Upcoming-Products/802-11r-Fast-Roaming/td-p/238085.

Každopádně, ať tomu budeme říkat jakkoli, s Unify, na kterém je i WPA (teď nevím jestli i WPA2, nemám teď jak ověřit, config jsem už dávno smazal a do controlleru se nemám jak dostat), prostě ty iPady s tiskárnama v restauraci fungovali tak, že při přechodu mezi AP se nerozpadlo RDP spojení, což je hlavní požadavek.

[Hatatitla]

Na stejném kanále to chodí o poznání lépe, klientům trvá přepojení na jiné AP o několik sekund méně.

??? a o niekoľko sekúnd menej?
Mám CAPS nasadený u pár klientov. Všade sú APčka na iných kanáloch WPA2 AES a prepnutie medzi dvomi apčkami vidím len ako prebliknutie v registration table z jedného ap na druhé. Dnes som behal po jednej ubytovni kde je aktívny CAPs ako apčka RB951 , netbook s WIN XP , pustené RDP na RDP som mal pustený winbox kde som sledoval ako ma prehadzuje medzi apčkami ked som prechádzal po budove.

[Petr S.]

Nemůžeš sem postnout konfiguraci? Pokud je to tak jak říkáš, docela by mě zajímalo, jak to máš nastavené...

[the.max]

Jak daleko máś APčka od sebe? V tom hotelu to je jen pár metrů. Co místnost to AP, protože mezi místnostmi jsou 100-160cm kamenné stěny (dům je přez 600 starý) a nedá se to rozumně prosvítit, nehledě k tomu, když servírky nosí tablety v kapse, stačí aby se blbě natočili a už je to na signálu znát. Pak když tablet vytáhnou a zapnou, tak na něm potřebují HNED fungovat.

[Hatatitla]

Nič extra len základný config ,
Interfaces , tie som len pomenoval nastavil a nastavil commenty , uvádzam dva ale všetkých 12 je nastavených tak isto

Kód: Vybrat vše

/caps-man interface
#
add arp=enabled comment=ap_spolocenska_1.p configuration=cfg1 disabled=no \
    l2mtu=1600 mac-address=00:0C:42:C3:D3:05 master-interface=none mtu=1500 \
    name=AP1 radio-mac=00:0C:42:C3:D3:05
#
add arp=enabled comment=ap_schodisko2 configuration=cfg1 disabled=no l2mtu=1600 \
    mac-address=4C:5E:0C:A9:BC:59 master-interface=none mtu=1500 name=AP2 \
    radio-mac=4C:5E:0C:A9:BC:59


A config :

Kód: Vybrat vše

/caps-man configuration
add channel.band=2ghz-b/g/n country=slovakia datapath.bridge=bridge-wifi mode=\
    ap name=cfg1 security.authentication-types=wpa2-psk \
    security.encryption=aes-ccm security.passphrase=******* ssid=*******


Na tomto rotry som nvytvoril bridge "bridge-wifi" bez interfaces , všetky sú len dynamické ktoré pridáva CAPs a na nom beží dhcp server. Klientov prepína v podstate hned .
Apčka sú rozmiestňované rôzne tak ako bolo potrebné podla signálov. Vnútorné priečky sú väčšinou 0,5m v polovici budovy je jedná nosná 1m hrubá. Win klienti a android zariadenia sa prepínajú okamžite.