CAPsMAN a použití u VoIP

[the.max]

Je to jen výtah, celé by to bylo dlouhé. b/g je tam proto, protože tiskárny se na b/g/n vůbec nepřipojí.

Kód: Vybrat vše

/caps-man channel
add band=2ghz-b/g frequency=2412 name=channel1
.
add band=2ghz-b/g frequency=2472 name=channel13

/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm,tkip name=WPA2-PSK-1 passphrase=**********
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm,tkip name=WPA-PSK-2 passphrase=********

/caps-man access-list
add action=accept comment="iPad vinarna" disabled=no mac-address=00:01:02:03:04:05 signal-range=-78..120 ssid-regexp=2
.
add action=accept comment="Tiskarna restaurace" disabled=no mac-address=00:01:02:03:04:05 signal-range=-80..120 ssid-regexp=2

/caps-man configuration
add channel=channel13 country="czech republic" datapath=datapath-br1 guard-interval=any hide-ssid=no mode=ap name=13-cfg-hoste rx-chains=0,1 security=WPA2-PSK-1 ssid=1 tx-chains=0,1
add country="czech republic" datapath=datapath-br2 guard-interval=any hide-ssid=no mode=ap name=13-cfg-tbl rx-chains=0,1 security=WPA-PSK-2 ssid=2 tx-chains=0,1


/caps-man manager
set enabled=yes package-path=/

/caps-man provisioning
add action=create-enabled comment="Pokoje 1" master-configuration=05-cfg-1 name-format=identity radio-mac=22:33:44:55:66:77
.
add action=create-enabled comment="Recepce" master-configuration=13-cfg-1 name-format=identity radio-mac=99:88:77:66:55:44 slave-configurations=cfg-2


[Petr S.]

Hatatitla: Takze jedno ssid a ruzne kanaly jsi psal? Jak to delas?

Mas tak taky nastaveny vyhazovani klienta z ap kdyz dojde k poklesu signalu?

[Hatatitla]

Petr S. bud to necháš na utomatiku , nenastavíš kanál , alebo si kanál definuješ pre každý interface zvlášť , aces list je tam nastavený na signáli , len kvoli tomu že sa klienti držali zo slabým signálom na jednom ap aj ked z iného by mali lepší signál ...

[Petr S.]

Petr S. bud to necháš na utomatiku , nenastavíš kanál , alebo si kanál definuješ pre každý interface zvlášť , aces list je tam nastavený na signáli , len kvoli tomu že sa klienti držali zo slabým signálom na jednom ap aj ked z iného by mali lepší signál ...

Jasně, ale jak to máš ty? V tvém konfiguráku jsem tohle vůbec neviděl. Tys tohle vůbec neřešil, a fungovalo ti to tak dobře?

[jarda.jezek]

Ještě bych se podíval, jestli to nezdržuje dhcp server. Tablety a telefony se často nepovažují za připojené, dokud čekají na ip adresu. Je-li jen jeden dhcp server v síti, zkusil bych přidělovat ip okamžitě autoritativně. Předpokládám, že ip jsou pevně svázané s Mac a každý klient má pořád stejnou ip.

[Hatatitla]

Petr S. bud to necháš na utomatiku , nenastavíš kanál , alebo si kanál definuješ pre každý interface zvlášť , aces list je tam nastavený na signáli , len kvoli tomu že sa klienti držali zo slabým signálom na jednom ap aj ked z iného by mali lepší signál ...

Jasně, ale jak to máš ty? V tvém konfiguráku jsem tohle vůbec neviděl. Tys tohle vůbec neřešil, a fungovalo ti to tak dobře?

Na tejto ubytovni nemám nastavené nič čo sa týka kanálov , len nastavený band na channel.band=2ghz-b/g/n
u iného klienta som sa stým hral a tam som manuálne nastavoval kanál pre každý interface . A prepína mi to klientov medzi apčkami okamžite. Jediné čo mi robí problémy sú urovne signálov , apčko si drží klienta do poslednej chvíle. To sa dá síce riešiť acces listom , ale je to dvojsečná zbran , niekde úplne za roho kde je signál len z jedného ap aj to slabý sa potom klient nepripojí vôbec , kde je tých signálov viac sa ale zasa zbytočne nedrží na nízkom datarate.
Možno by som ešte skúsil nastaviť šírku kanála na 20MHz , pokiaľ sa nenastaví tak pri b/g/n je 20/40MHz s čím majú ale problém niektoré staršie b/g zariadenia.

[Petr S.]

Ještě bych se podíval, jestli to nezdržuje dhcp server. Tablety a telefony se často nepovažují za připojené, dokud čekají na ip adresu. Je-li jen jeden dhcp server v síti, zkusil bych přidělovat ip okamžitě autoritativně. Předpokládám, že ip jsou pevně svázané s Mac a každý klient má pořád stejnou ip.

No pokud bude problem v tom, ze klient ceka az dostane od dhcp adresu,tak si myslim, ze se to nevyresi tim ze udelam na serveru vazbu mac - ip... Nebo se mylim?

[the.max]

Přikládám (necenzurovaný, aby se dali identifikovat přechody klientů mezi AP) log. V logu je sice krásně vidět jak se klient v jedné vteřině je připojen k AP a hned následně z jiného AP odpojen. Chápu to tak, že CAPsMAN zaregistruje připojení klienta k AP, následně zkontroluje reg. tabulku kde zjistí, že klient je zároveň připojen ještě na starém AP a tak záznam smázne. Proto je tam nejdříve připojení a pak odpojení. Následuje několik sekund a znovu se to opakuje, protože servírky se po place pohybují teď v době obědů vcelku rychle.

Z pohledu logu to vypadá krásně, ale z uživatelského pohledu je tak, jak jsem popisoval již minule. Tabletu trvá dlouho přepojení na jiný interface. Mám takový dojem, že CAPsMAN tohle v reálném čase nekontroluje, jestli klient je nebo není na AP připojen, resp. odpojení klienta z AP okamžitě nevyvolá akci pro odstranění klienta z reg. tabulky. Proto v logu jsou vidět sice krásné časy o přepojení během sekundy, ale reálně to trvá na tabletu podstatně déle. Tablet ztratí signál a hledá nové AP, což chvilku trvá. Když AP najde, tak se na něj zkusí přihlásit, Pokud nemá nízkej signál, že by ho AP nepustilo, tak probíhá ověření, což je další čas. A až v okamžiku, kdy je klient úspěšně zaregistrovaný CAPsMAN zapíše do logu hlášku o přihlášení k AP a prohledá reg. tabulku, viz výše.

[killa]

S "roamingem" na CAPsMAN síti také nemáme větší problém. Provozujeme teď už cca 60 apček a běžné aplikace např typu RDP "drží" při změně AP v pohodě Bez problému je i třeba takové applovské facetime audio. Nic dalšího, co je citlivé z pohledu roamingu jsme nezkoušeli. Klienti jsou převážně ipady, přechod z AP na AP fakticky nejde zaregistrovat. APčka svítí jedno SSID, každé samozřejmě na jiném kanále, 802.1x - PEAP. Sip call vyzkouším a dám vědět.

Vedle toho máme cca 200 cisco apček, kde jsou stejné konfigurační baseline - chová se to stejně. Samozřejmě je tam spousta dalších features, application aware shaping, cleanair, energywise, záložní kontroler atd. Ale zjistili jsme, že tam, kde vysloveně není potřeba enterprise řešení, je mikrotik zcela vyhovující. A ta cena! Budeme rozhodně kupovat další desítky kusů.

[the.max]

Asi mi něco uniká, ale pokud máš dynamicky vytvřený interfejsy na routeru jen tak, nemáš je v bridgi, jak tam tedy potom probíhá komunikace? To máš na každej ten interfejs extra dhcp server a když se klient přesune z jednoho APčka na jiné, tak zase dostane jinou IP?

[jardatop]

Rád se podělím o svoji čerstvou zkušenost s touhle problematikou. Zrovna jsem pokrýval signálem větší rodinný dům.
CPE a zároveň router je RB711. V síti mám tři kusy hAP lite RB941-2nD. Všechny jsou připojeny do sítě kabelem. První hAP lite je hned za CPE, další dva jsou z jednotlivých jeho portů. hAPy fungují i jako switche, v ostatních portech jsou připojené stolní počítače, SOHO switch atd. Jednotlivé hAP mají eth1-4 v modu switch.
Na CPE/Routeru mám spuštěny CAPsMAN2. Všechny AP mají stejné SSID, heslo a režim (2bgn, 20MHz), každé jiný kanál (1,6,11). Jednotlivé interfejsy cap1, cap2, cap3 mam v routeru v bridgi i s LAN portem RB711tky a tam DHCP server.
Kromě těchto tří cap tam mám ještě na každém jeden virtuální a ty jsou ve zvlášť bridgi pro hosty a tento bridge má svůj DHCP server.

V Access listu mám nastavený Signal Range na -80..120.

Na smartphonu s Androidem používám SIP klienta CSipSimple. Při přechodu od jednoho AP k druhému v hovoru jen lehce zaškobrtne, ale hovor se nerozpojí.

Při spuštěném Winboxu na notebooku se při přechodu od jednoho AP k druhému spojení ve winboxu neodpojí, všechno jede dál.

Roaming v pravém slova smyslu to není, ale pro potřeby VoIPu to funguje.

P.S.: Příště ještě vyzkouším skype hovor.

[joker]

Skype hovor bude to samo co SIP hovor nic se nerozpadne, neni duvod. Jde jen o to, jak rychle se klient prepne a jak rychle ho AP vezme... Coz u Mikrotika se mi zda ze trvalo v mem pripade dele (rekneme ze dvojnasobne, treba 2 vteriny celkem, nez u jinych krabicek, viz PS nize...

S "roamingem" na CAPsMAN síti také nemáme větší problém. Provozujeme teď už cca 60 apček a běžné aplikace např typu RDP "drží" při změně AP v pohodě Bez problému je i třeba takové applovské facetime audio. Nic dalšího, co je citlivé z pohledu roamingu jsme nezkoušeli. Klienti jsou převážně ipady, přechod z AP na AP fakticky nejde zaregistrovat. APčka svítí jedno SSID, každé samozřejmě na jiném kanále, 802.1x - PEAP. Sip call vyzkouším a dám vědět.

Vedle toho máme cca 200 cisco apček, kde jsou stejné konfigurační baseline - chová se to stejně. Samozřejmě je tam spousta dalších features, application aware shaping, cleanair, energywise, záložní kontroler atd. Ale zjistili jsme, že tam, kde vysloveně není potřeba enterprise řešení, je mikrotik zcela vyhovující. A ta cena! Budeme rozhodně kupovat další desítky kusů.

Jak to mate udelane, ze se apcka nerusi navzajem? Napriklad kdyz budou klienti apple, vyjde novy ios, vsechny zacnou na wifi sosat giga dat, apcka zacnou vysilat a myslim ze se dost zarusi...

Pominu ted backbone, dejmetomu ze je neomezeny, ale jak pridelujete kanaly a umistujete apcka, aby se neovlivnovala radiove?

Diky.


Ps: a ku veci roamingu: psal jsem ze mi to funguje bez problemu (stejne ssid a subnet - ap jsou v rezimu bridge, jiny kanal, wpa2), s ruznymi ap ruznych levnych vyrobcu mezi sebou, akorat s mikrotikem jsem mel vazne pocit, ze to na nej a z nej prepojuje dele nez obvykle (kdyz predtim byly obycejnejsi AP), klientem u me byly take apple hracky... Zadny caps jsem u mikrotika ani jinych krabicek nenastavoval...

Testoval jsem to pingem... Na tabletu treba PingAnalyzer apod..,

Voipem se to da take testovat, ale to si musite pustit muziku na pozadi, protoze to zaskobrtnuti nemusi jit ani slyset, muze vyjit do pauzy mezi slovy.

Podle tohoto vlakna se zda, ze diky tomu, ze ma Mikrotik vlastni "firmware?" tech radiovych cipu, tak to opravdu muze byt trosku problem?

[hapi]

no, pokud máš něco co si klienty přehazuje samo ve smyslu že klient o tom neví a ani neví že komunikuje s jinym ap, tak je to bez problému. Pokud máš automatický kopání klientů od nějakýho signálu nebo se klient snaží sám tak se musí znova rekonektit a tam to už trvá delší dobu a je to závislí na klientovy. Nicméně tu máš dvě různý věci, iniciativa klienta a iniciativa apčka.

[Majklik]

CAPsMAN v současné verzi (pokud beru cm2 balík) umí řídit jen konfiguraci koncových AP a dataplan (tunelování datových paketů). Neumí řídit controlplane, aby víc AP vystupovalo jako skutečné jedno AP. Takže přechod klientů mezi AP je plně v režii klientů, APčko maximálně pomůže vykopnutím klienta při slabém signálu, pokud is to v accesslistu nastavím.

[joker]

Ono to asi ani jinak nejde, stejne vetsina klientu ani asi neumi fix na AP na jeho MAC adresu, to snad jde jen v linuxu, ze?

A na telefonu (iOS) ani neni moznost zjistit MAC adresu apcka...

Takze klient si vybere nejsilnejsi AP a jde podle me jen o to, jak rychle ho dane AP prijme, a to dle mych zkusenosti se na ruznych AP deje ruzne rychle (i kdyz zabezpeceni je wpa2aes - vsude stejne).