Például a Cisco, az nem SOHO, cserébe űrmérnöki végzettség kell hozzá, meg olyan árai is vannak, mint az űriparban.
Félreértés ne essék, az Unifi előtt Cisco AP-k voltak, és egy pisszenés/hiba nélkül, tökéletesen tették a dolgukat, vagy 5 évig, tényleg, szinte észre sem vettük, hogy ott van a falon, mechanikailag, elektromosan, és "szoftveresen" (firmware) atom-stabilak voltak.
Viszont, amikor a vezetés kitalálta, hogy mostantól ne Radius, hanem, sima WPA2 legyen az authentikáció, akkor a cég, ami évekkel előtte a telepítést végezte, (és azóta nem kellett hozzányúlni) eléjük tett egy havi karbantartási szerződést, havi 1M HUF értékben, és, helyi, cisco-hoz értő ember nem lévén, a vezetőség beijedt. Ehhez jött, még hozzá, hogy azok az AP-k nem tudtak rendesen N-et, csak 54mbps-ig, így, amikor elavultak egyértelmű volt a váltás.
Nincsenek nagy igényeim, egyszerűen csak annyi, hogy amit ráírtak, akkor azt legyen szíves tudni is!
Megvettük az Unifit, felraktuk a Cisco helyére, és elkezdődött a szívás, ami különböző erősségű hullámokban, de azóta is tart.
1.) Az automatikus csatornák:
A automatikus csatorna-választás, mindjárt az első napon elhasalt, nem volt különösebben zsúfolt a 2.4-es sáv, egyszerűen, az AP-k egymás jelét is zavarnak érzékelték, és 2 percenként pakolták át magukat egy-egy újabb csatornára, és dobálták le a klienseket. (Mert a kontrollerből természetesen hiányzik az erre vonatkozó koordinálási képesség. (mind a mai napig egyébként))
Ezt át lehetett hidalni azzal, hogy kézzel beállítgattuk a csatornákat eltologatva, hogy a közelben lévő AP-k ne ugyanazon a csatornán beszélgessenek, és N-mód esetén, legalább 2 csatorna különbség legyen, két közeli AP között.
2.) Az 5GHz:
Az 5GHz-en is ki lettek osztva a csatornák, kevés eszközzel, az elején, de jól működött, egy évvel később jött be a kötelező DFS, amit mindjárt implementáltak is (természetesen szarul) az Unifi-be, és megint ott voltunk, hogy 2 percenként ugrottak a csatornák, de legalább ezt már csak az 5G csinálta, a 2.4 nem.
Miközben bőven elég kellett volna legyen a 124-126 csatornákat kihagyni (ezt meg is tettük), mert Budapesten csak az OMSZ radarja működik 5625MHz-en, ehelyett az AP-k állandóan egymást, és a távoli kliensek csatlakozási kísérletét nézték radarnak.
Ez 2.5 évig ment így, teljesen használhatatlanná téve az 5GHz sávot.
Mostanra valamit javítottak, mert már "csak" napi 2-3db Radar-detection értesítést kapok, így már nagyjából használható.
(természetesen kizárólag kézi csatornakiosztás mellett)
Megjegyzem:
Az Igazi Openwrt-ben csak mostanában kezdték el implementálni a DFS-t, és már jobban működik, mint az Unifiben.
3.) DHCP, POE, switch
A hozzájuk tartozó Unifi Switch-eket, az első héten küldtük vissza, mert nem tudtak VLAN-t kezelni, egyszerűen nem volt bennük ilyen funkció, így (hasonló árkategóriájú) 802.3 af/at -képes TP-Link switchek hajtják az AP-kat.
A fent említett DHCP-hibákra állandóan panaszkodik az Unifi controller, (400 usernél, napi 600-800 "anomália", jelentsen ez bármit is) de vagy az userek türelmesek, vagy tényleg nem tapasztalnak hibát, mert nem jeleznek "internet" hibát, és a (Debian, ISC DHCP) szerver logjai alapján is rendben vannak.
De, azt észrevettem, hogy arra hárklis az Unifi, és újrakezdi az auth-folyamatot, hogyha valamiért (pl: egyszerre sok kérés érkezik be) egy "picit" lassabban válaszol a DHCP, és nem "azonnal". (azért van idézőjelben, mert tudok ide vonatkozó milliszekundumokat kimérni)
4.) WPA3
Most az a legújabb, hogy a WPA3 támogatást már a régebbiekbe (pl: UAP-AC-PRO) nem teszik bele, hanem megvetetik veled az újabb U6-szériás AP-kat, holott az OpenWRT-ben benne van, így most azon tűnődök, hogy mi lenne, ha hagynám a fenébe a Controllert, és telepítenék mindegyikre eredeti OpenWRT-t...