UniFi UAP-AC-Lite 2.4GHz ügyfelek leszakadnak

Wireless

Üdv!

A tárgyban írt 3 éves eszközhöz időnként megzavarodik és az addig kapcsolódott eszközök közül néhányan leesenek és nem is tudnak visszamászni. Ilyenkor az UniFi Controllerből újraindítottam és működött ismét. Ezt úgy egy éve kezdhette el.

Volt olyan, hogy este otthagyták a laptopot bekapcsolva, hogy másnap reggel megnézhessem a hibát, de reggel már magától csatlakozott állapotban volt ismét.

A sok esetből annyit már sikerült levonnom, hogy ez a 2.4GHz-cel csatlakozó eszközök sajátossága, közte egy wifi-s nyomtatóé is. Amikor kiakad a nyomtató, azt mutatja, hogy kapcsolódva van, de pingre nem válaszol.

Csak magukat az eszközöket újra indítva sem javul meg a kapcsolat. Akkor sem, ha letiltom a wifi kártyát majd engedélyezem, vagy eltávolítom és visszatelepül (driver marad). Törölhetem a wifi hálózatot a gépról, majd újra felvéve sem segít

Mindenképpen az AP-t kell újraindítani.

Egyszer-egyszer az 5GHz-s laptopokon is elmegy a kapcsolat de ez fehér holló.

De az utóbbi időben már napi többszöri probléma lett a 2.4-es gépek kálváriája.

A héten nem jártam arra, ilyenkor azt csinálják - amit totál nem értek miért oldja meg - , hogy az internetet  adó Drytek routert kapcsolják le majd vissza. Itt az a láncolat, hogy UPC modem -> Drytek -> 8 portos switch -> AP. De megoldja.

Fw a legfrissebb, controller a legutolsó szintén, szünetmentesen lóg a PoE feladó. Csúcson kb 30 eszköz lóg rajta.

A környéken rengeteg AP van, 50-60db is. Az AP csatornaválasztója auto-n van, néha szoktam engedni, hogy nézzen körül és keressen üres(ebb) csatornákat.

Eddig bitang jól működött a wifi, semmi panasz nem volt rá. A 10 éves Drytek lesz majd lecserélve egy ER-12-re hamarosan.

Google nem segített eddig. Nekem azon kívül, hogy veszek egy újat és reménykedek már nincs ötletem.

Bárkinek van tapasztalata, ötlete?  Köszönöm!

 

Bónusz pálya: Az IP cím osztó Drytek router ki/be kacsolása miért hozza rendbe az AP-hez kapcsolódást?

( andrej_ v | 2021. 10. 09., szo – 13:20 )

Az első tippem, hogy túlmelegszik esetleg a rádiója, illetve a többiek túlságosan zavarják egymást. Próbáld meg kicsit visszavenni az adóteljesítményt, nekünk Cisco AP-kkel volt ahol segített.

A második tippem, hogy simán a bluetooth-okkal meg mindennel a 2,4GHz-es sáv simán totál tele van ott. Esetleg néhány közeli AP üzemeltetővel egyeztess, hogy náluk nincsenek-e anomáliák. Ha vannak, akkor hátha hajlandóak visszavenni az adóteljesítményt, mert ha nincs csutka térerő minden sarokban, az valszin vállalható.

Nem megoldható... naaaaaa... Nem is biztos, hogy mindenkével kéne, de mondjuk a közeli 5db-bal valszin nem lenne lehetetlen. Gyanús, hogy ugyanezzel a problémával kűzdenek és szídják a netet, mint a bokrot. Ebben amúgy üzleti lehetőség is van. :) Nem egyeztetsz, hanem Wi-Fi finomhangolást reklámozol. :)

Itt egy emberke osztja a tapasztalatát.

Azt találtam, hogy bekapcsoláskor választ 2.4-es sávot, az auto power pedig a maximumon tolja.

Before we begin, though, let’s talk about “auto.” Unifi APs do indeed have an “auto” setting for both power and channel selection, and you should never use either of them. The transmit-power “auto” selection is misleading—it simply locks the AP’s radio at its highest power setting, which is almost certainly not what you want.

Berakom mind a két beállítást fix-re.

( uid_6201 v | 2021. 10. 09., szo – 14:05 )

Szerkesztve: 2021. 10. 09., szo – 14:15

Wifi analyzer (Android) alapján mennyire "küzdőtér" ott a 2,4 GHz? Ha teli van wifi AP-vel, akkor auto nem szerencsés, helyette kisebb távolságra tett AP-re célszerű csatlakozni, amiben fix a csatorna. Ha több AP-d van, ne azonos SSID-jük legyen.

Illetve amível csak lehet át kell menekülni 5GHz-re. Ott kisebb egymás zavarása.

Küzdőtér a 2.4. Kedden frissítem a tudást.

Ez irodában az egy AP van. Fixáltam a csatornát. Szombat éjjel nyugis volt a vidék, egyelőre ez alapján választottam.

Egyébként ha auto-n van akkor hogyan dolgozik? Rakosgatja magát óránként és gyertek utánam eszközök?

5 GHz ellen miért ellenkezel? Több okból is sokkal kisebb a rádiófrekvenciás zavartatásod.
Ez nem ideiglenes teszt, hanem az 5 GHz-re erősen célszerű átállni. Ha nem a legalsó csatornákra költözöl, tuti sokkal kisebb lesz itt a rádiófrekvenciás zavartatásod.

( joco01 v | 2021. 10. 09., szo – 15:37 )

Egy világ dőlt össze bennem (AP vásárlás előtt állok). Sub.

+1, szerencsére nagyon nincsenek elszállva az árakkal, ennyiért még sokkal jobbat nem kapsz, bár mondjuk a belépő szintű instant Arubákkal nincs tapasztalatom, papíron jobbnak néz ki  A hasonló árú többiek meg szoftveresen kérdésesek. Az Ubi legalább jó lóra tett az OpenWRT alapokkal és igyekszik követni is. Nekem a Java alapú központ se hàtrány, mert csomó mindenen elfut.

( vl v | 2021. 10. 09., szo – 15:51 )

Én visszaraknám azt a fw-t, amivel korábban jó volt.

És akkor kiderülne, hogy a szoftveresen "romlott el", vagy a hardverrel lett gond. Erős tippem volna amúgy az elsőre.

( b10up | 2021. 10. 09., szo – 16:16 )

Nálunk több balhé is volt. 
Egyik az a bandwidth steering, ami próbálta 5g-re tuszkolni az eszközöket, az néha okozott szakadozást. Néha csak a sima 802.11r support bekapcsolt állapota is. Apple laptopok simán nem bírtak akkor feljönni sem.

Másik pedig egy-egy konkrét wifi kártya volt. Igaz időben sok hónap eltéréssel okoztak bajt.
Amikor az az eszköz csatlakozott, több, vagy az összes eszköz megbolondult azon a frekin. Egy LG TV és egy sima Azurewave kártya is csinálta.  A szép az volt az egészben, hogy a balhés wifi kártyával 1-2Mbit/s tempó megvolt, de a jó kártyák leszakadtak.  És mindkét kártya egyébként n-es volt.

( VincentV | 2021. 10. 09., szo – 18:26 )

Szerkesztve: 2021. 10. 09., szo – 18:29

Ugyanez van nálam is egy UAP-AC-PRO-val, 3 napja kezdte. Vannak erre sírások az ubnt fórumon, de nekem sem áll össze a kép, mert:

- leszarom üzemmódban működik, utoljára én is ~1 éve frissítettem fw-t (4.3 volt rajta), mégis egyik napról a másikra megtörtént ugyanez

- controller verzió, kliensek száma, egyéb összetevő nem változott

- nincs plusz zavaró hálózat sem, falusi környezet, 1db szomszéd TP-Linkjét látom minimál jelerősséggel, de ennyi

Ami érdekes, hogy az AP saját logjait elnézve feltűnt, hogy a döglés alatt warningol arra, hogy nem válaszolnak a kliensek a DHCP offerre. Ez ugye azt jelentené, hogy volt request is.. És tényleg, a Mikrotik router logjai is tele vannak vele, hogy jött request, de az offerre nem érkezett válasz. A DHCP forgalmat amúgy a DHCP snooping miatt figyeli az AP, de nem ezzel van ilyenkor gond, ez csak egy olyan dolog ami nyomot hagy a logokban. Ilyenkor azoknál a klienseknél akiknél még nem járt le a lease, szintén azt tapasztalom, hogy az AP irányában tudnak forgalmazni, de a visszafelé irány (AP->kliens) halott. Ezért nem megy a dhcp _se_.

Először én is hw hibára, és cserére gondoltam, de további fejvakarásra adott okot, hogy egyébként meg autholnak, key exchange megtörténik, szóval a client association lefut, és belépnek. Azaz olyan, mintha az L1 forgalom kétirányú lenne, de az L2 már nem. Ráadásul az ubnt fórumain levő lázadás ugyan rímel rá (DHCP snooping, és 5.43-as firmware esetén gondok a 2.4G-s hálózattal), de közben mégsem, mert csomó ponton eltérés van nálam. Közben a hibajelenség meg ugyanaz. Teljesen érthetetlen a dolog.

Most feltettem én is a latest firmware-t (5.43.46.12754), egyelőre ~20 órája minden oké, de az utolsó döglés előtti napon is ment vagy 22 órát.

Hmm, DHCP request?

Ez azért érdekes, mert ennek a hálózatnak NEM az AP oszt IP-t, hanem a Drytek router. Az AP-n van egy VLAN is, ott az AP osztja az IP-t.
(A VLAN-os hálózaton fejlesztők vannak, ők azonnal kiabálnának, de lehet nincs is 2.4-es eszközük.)

Ugyanakkor a HP nyomtató nálunk fix IP-s és ő is elérhetetlen ilyenkor.

Egyik UAP sem tud DHCP szerver lenni, de lehet hogy félreértem amit írsz... A Unifi ökoszisztémában az USG-nek van DHCP szerver szolgáltatása, illetve az utód megoldásoknak (UDM, meg a franctudja, annyira nem követem), illetve lehet saját megoldás is persze, nem kell feltétlenül Unifi. Viszont Unifi-on belül a switchek, az UAP-ok, és maga a Controller se tud ilyet. De nálad is egy router (Draytek) a DHCP szerver, nem?

Lehet én értek félre valamit vagy amit beállítok az nem az. :)

A Network menüben vannak a hálózataim. Erre állítottam be DHCP-t szándékom szerint. De megnéztem és valóban van erre a VLAN 2-re DHCP beállítva a Draytekben is.

Ezt akkor egy picit most nem értem mit csináltam a múltban.

upd: teljesen igazad van! USG vagy mint esetemben egy router kell hozzá.

Jelentem a probléma teljesen megszűnt, az 5.43.46.12754 úgy tűnik hogy megoldotta a dolgot még akkor. Túl sok logikát nem látok benne, hiszen egy olyan régi firmwaren voltam előtte, amit nem volt érintett abban a hibában, amit a fenti firmware javított volna. Mindegy, nagyobb baja sose legyen, ez is csak ilyen gyakorisággal (3-4 év alatt ez volt az egyetlen gondom vele).

( SCOPE | 2021. 10. 10., v – 03:45 )

Szerkesztve: 2021. 10. 10., v – 03:53

Nekem van szerencsém, már 6+ éve gyűrni egy közepes/nagyobbacska UAP-PRO hálózatot, (~20db AP, ~400 (max)kliens) tapasztalatok a következők:

1)
A Látszat, és mindennemű marketing bullshit, verzió ellenére 12-15db kliens/AP a max, de az optimális az 8db körül van, efölött elkezdenek lassulni az egyes kapcsolatok.

Ezek ugyanolyan SOHO eszközök, mint a TP-Link, ugyanakkor, ha sok időd, és türelmed van az istápolásukra, akkor elmennek kiscéges környezetben is. Annyira SOHO, hogy néha még a firmware-ből is elfelejtik kiszedni az OpenWRT logót...

Ez olyannyira igaz, hogy a legújabb U6-Lite AP-jükben egy kommersz MT7621 ketyeg.

A központi mgm felület is egy bullshit, úgy, ahogy van, kizárólag a "kinézetre" hajtanak, a funkcionalitás, szinte minimális, a kötelezőt hozza, de semmi "extra" opció. Java alapú, és mint olyan, zabálja a RAM-ot, most ott tartunk, hogy 2hét futás után, már 4GB-t felzabált, de szokott az több is lenni. Ami különösen idegesítő benne, hogy néha, ha valami új dizájnt találnak ki, már akkor is ráderőltetik, amikor még nincs meg benne egy csomó opció, ami az előző verzióban, még benne volt, nemhogy új opció. (Persze, ilyenkor ált. visszahozható a régi felület.)

És, ha még ez nem lenne elég, akkor szoktak olyat csinálni, hogy az mgm felület frissítésekor ki-be kapcsolnak funkciókat, a te értesítésed nélkül.
(Pl: a "fast-roaming" Hopp, egyszercsak észreveszed, hogy be van kapcsolva, holott nem te kapcsoltad.)

Egy ilyen "híres" eset volt, amikor az EU kötelezővé tette a DFS-t, ekkor úgy 1.5 - 2 évig lehetetlen volt 5GHz-en az AP-khez csatlakozni, egyszerűen Radarnak érzékelték egymást az AP-k, és percenként cserélték automatikusan a frekvenciájukat, 2 éve kellett, mire az UBNT-nek sikerült megoldani...

Ha az eredeti OpenWRT-ben lenne központi mgm lehetőség, és fast-roaming, már rég feltettem volna rájuk, az Unifi firmware helyett...

2)

Ami a Wifi beállításokat illeti:

- Az első, amit el kell dönteni, az a "Legacy eszközök" tiltása, vagyis, hogy ezentúl csak N-es eszközök csatlakozhatnak-e, vagy engedjük a "régi" 802.11b, és g eszközök csatlakozását is. Ha igen, akkor ne csodálkozunk a lassuláson, mert amíg a b/g eszközökkel beszélget az AP, addig az n-esek ki vannak rekesztve és várnak a sorukra, de ez így van az otthoni rúternél is, csak legföljebb nem vesszük észre, viszont úgyhiszem, 2021-ben már nem teljesíthetetlen követelmény a kizárólag N-es eszközök engedélyezése.

- A "Multicast filtering"-et nem muszáj használni, helyette javasolom inkább az egyes wifi-ssid -k szerinti külön VLAN-ba sorolást.

- A "Fast Roaming" mehet, ha csak N-es eszközök vannak engedve, ekkor, amelyik még 2008 előtti N-es, kicsit hátrányban van, de nem okoz olyan nagy galibát azoknál a klienseknél sem.

- A "Proxy ARP" nálunk segített, csökkentette a fölöslegesen rohangáló ARP forgalmat

- Az "L2 Isolation" nálunk követelmény, tehát be van kapcsolva.

- A PMF, Wpa3, Radius, opciókkal kísérleteztem.

- A "Band Steering" nálunk működik, igaz nem lett kiegyenlített a hálózat, mert a kliensek ~30%-a tud csak 5GHz-et, és történelmi épület vastag falakkal, így sok helyen nem is fogható.

- Az olyan trükkök, hogy egy bash script éjjelente körbe SSH-zik az AP-ken, és újraindítja őket, szoktak segíteni.

Az Unifi Dashboardon megjelenő DHCP timeout/failure, és hasonló hibaüzenetek is baromságotk tudnak lenni, nem tudom, honnan veszi, de amikor a kezemben van a kliens, és szempillantás alatt sikeresen felcsatlakozik, (Linux DHCP server logja által megerősítve) akkor is van, hogy hibának érzékeli...

Pillanatnyilag a 5.43.43 firmware van rajtuk, de most, hogy írjátok, hogy a legújabb fw-vel hibák vannak, nem is fogok egy darabig frissíteni...

Én is innen vettem a javaslatot UniFi-re és előtte minden egyéb Asus, TP-link, D-link eszközök voltak, de állandó volt a panaszkodás, ahogy nőtt az eszközök száma.

Erre váltani  olyan volt, mint földútról kiérni autópályára. Most kb 30-35 eszközt szolgál ki, és amikor megy nagyon kényelmes.

De most pénteken négyszer indították újra a Drytek routert*, ami gőzöm sincs miért, de hatott az AP-ra is, mert tudtak utána csatlakozni az eszközök.

* Ezt osztja az IP-t az AP-s kapcsolatoknak, ez esetleg érdekes lehet.

Azt is érdemes megnézni, hogy tényleg kapcsolódni nem tud vagy pedig ip-t nem kap / netet nem lát. A felhasználók midnenre azt mondják, hogy nem tud kapcsolódni.

Ha központi felhasználókezelés van, akkor lehet nem is az AP-vel van baj, hanem ő nem éri el jól a hálózatot, azért nem enged fel senkit. Például mert valaki okos kolléga rádugott egy routert lan porttal bekapcsolt dhcp-vel a hálózatra és aki "közelebb" van hozzá, az tőle kap néha ip címet és az ő szarjának a beállításait kapja meg az eszköz. (kellett mégegy port és volt otthon egy tplinkje, behozta) Vagy egy rég elfeledett szolgáltatás maradványa fut még valamin, ami szintén ilyet csinál. Futtas valami dhcp tesztelő utilt, hogy hány helyről kap dhcp kérésre választ a végpont. 

A nyomtató fix IP-s és ki/be kapcs után sem lehetett pingetni a nyomtatót. Hajlok rá, hogy talán mégsem DHCP probléma.

Az irodai lányok között partizánok talán nincsenek, de elültetted a bogarat a fülembe a fejlesztőkkel kapcsolatban, bár ők külön VLAN-on vannak másik IP tartományban. De azt kipróbáltatom, hogy ha lehal a net, akkor a fejlesztőkhöz tudnak-e olyankor kapcsolódni.

Aruba, Ruckus...de szerintem jobb hozzászoknod, hogy nincs királyi út!

Gyíkja mindennek van/lesz. Ha ez a tény zavar, akkor szolgáltatást vegyél és ne hw-t...és akkor más szív vele helyetted.

A közfelfogás az, hogy 2021ben a wifi már nem űrtechnológia és PnP működnie kell faszán. Ezzel szemben pedig urbánus környezetben szerintem egyre komplexebb és egyre nagyobbak az igények, ergo egyre nagyobb szívás. (ld. az 5GHz-s igényedet 2 falon keresztül)

Ezeknek az árából veszel 3-4 soho vasat és ha behal, cseréled a fiókból. Bár most (szerintem) elég durva ütemben jönnek az egyre újabb szabványok, szóval lehet, hogy nem is érdemes betárazni.

"The only valid measurement of code quality: WTFs/min"

Mert sokkal jobban mennek, és roamingolnak szépen az eszközök közöttük. Anno egy távoli helyen nekünk bőven 200-300 körüli eszköz is előfordult a Wi-Fi hálózat (saját és guest együtt), mert laptop + tablet + mobil. Elsőre occóért kellett próbákoznunk, de összevissza megálltak az AP-k, meg újra kellett indítani, meg lassultak. Ha jól emlékszem, akkor csak a vezetőséghez került egy plusz AP, illetve a konferencia részre sokkal több, de az eleve másik épület. Szóval a főépületben hirtelen megszűntek a Wi-Fi problémák, úgy, hogy utána jóval több eszköz volt, azaz simán 10-15 eszköz volt egy-egy AP-n.

Ha végigolvasod a szálat, akkor látod, hogy ez alapvetően nem Unifi probléma.

Jött már szembe ez a mondat az elmúlt 1-2 évben párszor. Most már tényleg megnéztem, igaz, csak felületesen :) Jól látom, hogy itt is telepíthető a controller on-prem? Tudja azt, hogy semmi nem telefonál haza, és teljesen cloudmentes? Az nem zavar ha regisztrálnom kell, de utána semmit ne akarjon a cloudtól, ide értve a controller user authját is.

Igen, lehet local, és cloud controllered is.
A local verzió teljesen önjáró, ha nem adsz neki NET-et, akkor is gond nélkül megy. (max azt nem látja hogy van pl. AP firmware upgrade lehetőség)
Nem jellemző rá a fagyás, ha nincsen vele dolgod, akkor akár évekig is eljár úgy hogy be sem néztél a controllerre, újra sem volt indítva.
AP-k nagyon stabilak, nagyobb kliensszám esetén sincsenek gondok.

Mi is végigjártuk UniFI vonalat, utána jött Cambium és Cisco, ezekkel nincsenek gondok. (persze más árkategória is)

Accesspoint-tól lehet hogy tudtok kérni demo készüléket, érdemes lehet kipróbálni.

Pár hete megy egy nagyobb cambium hálózatunk cloud controllerrel, és nemsokára 150+ AP körül fog járni.

Stabilitási probléma nincs, pedig komplexebb beállítások vannak (több SSID, több VLAN/subnet mögötte, 802.1x hitelesítés, captive portal hitelesítés). Viszont e410-nél fogtunk egy firmware bugot, nem megy a 802.1x hitelesítésű hálózatban a client isolation, a captive portalos vendég hálózatban meg igen. Az XV2-nél meg mindenhol :)

Local controller is lehet, de az alap cloud controller ingyen van. És "csak" metaadat megy ki. De más szektor, más követelmények :) És az AP-kra 5 év gari van.

Azért nem egy Aruba vagy Cisco, azokkal út közben csomót kötsz a bitekre ha szeretnél. Itt vannak azért limitációk. De cserébe töredéke az előző 2 nagy gyártó bekerülési költségéhez képest, és átlagos vállalati igényeket ki tud stabilan szolgálni jó ár/teljesítmény mutatóval. De pl. érdemi wireless IPS-ről ne is álmodj :)

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...

Az UBNT Edgeswitch tudta, de az nem Edgeswitch volt, hanem UBNT Unifi swtich, viszont abban igazad van, hogy néhány hónap, fél évvel később érkező frissítéssel már tudták azok is, de mi azt nem vártuk meg, el kellett indulni. Egyébként azokat a TP-Linkeket nem bántuk meg, mert stabilak, és jól használhatóak voltak, de a mostaniaknak már kezd szintén nagyon hülye menüje lenni.

Ez nagyon hihetetlenül hangzik, mi volt a pontos típusuk? Tudtommal Unifiban soha nem volt olyan switch ami ne tudott volna vlant (már a megjelenésekor), eleve nem is illeszkedne a képbe sehogy. Persze ettől még lehet, ezért is kérdezem, mert kíváncsi lennék rá, hogy tényleg volt e ilyen. Most van itthon egy Unifi flex mini, kb. cigisdoboz méretű filléres switch, de még az is tudja.

Bocsánat, megkoptak az emlékeim, utánanéztem, nem kezelni nem tudta, hanem bug-ok voltak benne:

https://community.ui.com/questions/UniFi-Switch-48-POE-500W-problem-wit…

https://community.ui.com/questions/UniFi-Switch-Important-Notices-in-re…

mert ar-ertekben jo, ha nem a legjobb.  nyilvan nem a ruckus/cisco vonallal kell osszehasonlitani... sem arban, sem tudasban.

en uzemeltetek kb 300 unifi ap-t, szinte minden tipusbol van az elso uap-tol az u6-lr-ig, sok ugyfelnel, van ahol csak 2-3db van ahol 45. es nem szokott nagyon gond lenni veluk. ha leszakadnak a kliensek, annak altalaban az az oka, hogy a visszairany gyenge, a kliens (jellemzoen valami gagyi kinai telefon) nem eleg "hangos" amikor valaszol, de ez latszik is a controllerben. ilyenkor lejjebb kell venni a tx powert, es ha kell berkani tobb ap-t. vagy valami (pl. idegen ap) zavarja, de ujabban ezt is mutatja a controller (interference detected), es at is megy magatol masik csatornara.

regebben volt olyan hogy 200-300 nap uptime utan elkezdtek leszakadni ap-k a controllerrol, naponta tobbszor jott riasztas hogy disconnected de par perc utan megint connected volt. eleinte halozati/switch hibara gyanakodtam aztan kiderult hogy az ap hulyeskedik, kellett egy reboot neki. de ezt gondolom mar javitottak par eve, mert azota nem tapasztaltam, pedig van 500 napos ap-m is.

azt viszont osztom, hogy a controller frissitesek altalaban egyre rosszabbak, mindig elveszik 1-2 feature a nagy design valtasban, es ritkan raknak bele olyan pluszt amiert egyaltalan megeri frissiteni... meg elofordultak bugos firmware verziok is, de eleg ritkan (2-re emlexem az elmult 8 evbol). mondjuk en nem szoktam elkapkodni a frissitest, se ap se controller eseten, es elobb 1-2 kis ugyfelen tesztelem aztan ha nincs panasz mehet a nagyokhoz is.

( n.balazs v | 2021. 10. 10., v – 14:58 )

Én elgondolkodnék egy tápcserén az AP-nél, ha megoldható. Hátha segít.

Lesz tisztán PoE portos ER-12, de addig is az itthonival tényleg megpróbálhatom kicserélni.

De egyelőre még nem, mert csatornákat és jelerősséget is fixre állítottam. Meglátjuk ezek segítenek-e.

Emberkísérlet zajlik, de legalább tudnak magukon segíteni addig is a router ki/be kapcsolásával.

( crypton | 2021. 10. 10., v – 20:30 )

Hasonló tapasztalatok:

Instabil hálózati kapcsolat, (stabil wifi esetén) hasonló problémát okozott nálam a AP-kat kiszolgaló Unifi PoE switch fw frissítés után. 

Leszakadások, kapcsolat esetén local eszköz elérhetetlensége, lassulások - mobilokról eltűnő WiFi volt a tünet.

Revert az előzőre firmware verziora ezt megoldotta.

További Wifi furaságok voltak / megoldva:

Viszont egyik nap arra ébredtem hogy nincs 2.4. Csak 5 az egyik AP-n. Erre az volt a megoldás, hogy a CSAK az újabb controller felületen látható (calssicon nincs!) alap ON volt a bekapcsolva hagyott WIFI AI ami scannelgett folyamatosan és állítgatta a WiFi-t. Le is tiltottam azóta stabil minden.

A WIFI3 security (PFS? talán) kikapcsolása/bekapcsolasa pedig kékhalált okozott az online Win10 gépeken, illetve ha nem volt letiltva teljesen, akkor a nyomtató sem tudott felcsattanni wifire. Ez default optional, de csak teljes off-ra téve lett minden eszköz stabil.

Band steerings, fairness off.

( zolej v | 2021. 10. 11., h – 08:40 )

Egy ideje (> 1 év) én is küzdök. Egészen jól ment odáig, aztán szakadások történnek elég sűrűn.

A Dashboard is figyelmeztet (High tcp latency, Too many retries, stb...) és a Unifi fórumán is rengetegen panaszkodnak erre.

Sokan a firmware downgrade-et ajánlják, próbáltam pár hónapra / évre visszamenni, de nem lett jó megoldás.

Lehet, hogy magát a controllert is vissza kellett volna állítani az idősíkon. De ahhoz nem volt kedvem, túl sok a kliens beállítás benne.

Nekem dockerből fut a controller, annak az elérésével soha nem volt probléma, a hálózatunk is viszonylag egyszerű.

Mindenféle csicsa és extra feature kikapcsolva.

( ncc1701 | 2021. 10. 12., k – 12:24 )

Vicces, de vagy fél éve hajintottam ki otthonról a unifi ufómat, pont szakadozások miatt. Lett heyette egy mikrotik. A fentiek sok mindent megmagyaráznak.

( vudumancs | 2021. 10. 12., k – 12:42 )

Nezd meg a POE SW-n milyen az Uplink típusa. Nekem volt hogy billegett 1000/100 között (elötte nem volt hiba, aztan voltak szakadások, fura lassulasok, aztan lattam hogy a kapcsolodas sebessege 100 majd ujrainditas utan 1000 de idovel ujra random jött az esemény.), kabelcsere vagy a végek ujrarakása megoldja ha ez a gond. (elötte is cat5e volt utána is.) Ha kabelcsere nem lehet, de meg akarod nezni hogy tenyleg a kabel-e a ludas, egy hosszu lengo a teszthez.

Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.

( elod v | 2021. 11. 03., sze – 10:05 )

Szerkesztve: 2021. 11. 03., sze – 10:06

Most lesz aktuális a döntés, nem nyitnék más témát.

Erősködjek a Unifi vonalon (van vele már vegyes tapasztalat) vagy nézzem meg jobban az Aruba Instant On vonalat? Inkább az utóbbi felé hajt a kíváncsiság.

Kis telepítés, max 7 AP, egy switch, wifi hálózatból nagyon kevés van a közelben.

4 db Aruba Instant on AP22 van felrakva egy cég irodáiban. Év elején lettek lecserélve az Unifi AC-LR-ek. Sebesség szempontjából nagyon jó, gyorsan csatlakoznak a kliensek, stb.

Cloud-os controllerrel nincs gond, amit beleraktak az jól működik.

Egyetlen észrevétel, hogy néha a kliensek nem az abban az irodában lévő AP-ra csatlakoznak és nem akarnak átállni.

Egyébként csak pozitív a tapasztalat.

A Unifi LR-hez képest látsz különbséget térerőben/sebességben/hatótávban? Én is vételben gondolkozom, otthonra, kb. 2 falon kellene átlőni a jelet, a Unifi LR az állítólagos jobb hatótáv miatt érdekel, de szívesebben vennék valami még jobb kategóriát (pont emiatt a topic miatt), és ebben az árban nagyon nem mindegy, hogy egy vagy két darab kell belőle :).