Wifi roaming

[pieterbeun]

Beste tweakers,

Wij hebben thuis een probleem, en waarschijnlijk ben ik niet de enige met dit probleem.

Wij hebben thuis meerdere wifi punten. alleen met het overschakelen van punt A naar B gaat niet altijd lekker. Ik heb er al veel over gegoogeld maar zoiets is alleen mogelijk met duurdere wifi oplossingen. kan dit niet simpeler?

Het netwerk heeft hezelfde SSID en zit in hetzelfde subnet (192.168.1.0). en gebruik het volgende:

Fritzbox 7560
Ubiquiti AP light
TP-link 1043.

[Ben(V)]

Allereerst moeten alle setting gelijk zijn, behalve het kanaal dat moet verschillend zijn voor elk AP.
Verder geen AP op auto zetten.

En dan het belangrijkste.
Roaming wordt beslist door je device en niet door een AP.
Meestal heb je veel te veel signaal van je AP's ten opzichte wat je devices kunnen leveren.
Het effect is dat je device nog denkt , "ik heb prima signaal van m'n AP, dus waarom zou ik roamen", terwijl doordat je device veel minder vermogen heeft, dat AP niet bereikt kan worden.
Gevolg wel connectie, geen communicatie en geen roaming.

Oplossing:
Draai het vermogen van je AP's zover mogelijk terug, zodanig dat je net overlap hebt en niet meer.

[ Voor 17% gewijzigd door Ben(V) op 22-07-2018 15:01 ]

[laurens0619]

Je kunt betere de minimale linkrates uitschakelen, dat is effectiever dan vermogen terugschroeven.

Verder is roaming met mixed ap’s/fabrikanten/modellen een beetje geluk hebben. Het beste restultaat haal je bij roaming als alle ap’s van dezelfde fabrikant zijn.

Verder is dit goed leesvoer: http://wifinigel.blogspot...e-sticky-clients.html?m=1

[ Voor 15% gewijzigd door laurens0619 op 22-07-2018 20:57 ]

[Ben(V)]

Geen idee wat minimale linkrates zijn.
Kun je dat uitleggen?

[RGAT]

Ben(V) schreef op maandag 23 juli 2018 @ 10:30:
Geen idee wat minimale linkrates zijn.
Kun je dat uitleggen?

Zodra het wifi signaal omlaag gaat, volgt de linkrate vaak ook, dan krijg je bijv. een 20Mb verbinding op een 300Mb AP en als je beter signaal hebt gaat de linkrate terug richting die 300Mb, vooral de lagere rates uitschakelen zorgt ervoor dat dit niet zo ver kan en de client eerder disconnect, ook als er nog signaal is.

[dion_b]

Ben(V) schreef op maandag 23 juli 2018 @ 10:30:
Geen idee wat minimale linkrates zijn.
Kun je dat uitleggen?

Wikipedia: IEEE 802.11g-2003 Data rates

Zie dit lijstje. Dit is voor WiFi-a/g, maar je hebt ze evengoed voor alles van b tot en met ay.

De data/link rate is een combinatie van instellingen (aantal datastromen, kanaalbreedte, guard interval lengte en modulatie) die samen een bepaalde bruto throughput voorstellen en bovenal afhankelijk zijn van de SNR van een verbinding.

Als twee WiFi-apparaten een verbinding proberen te maken, wisselen ze hun capabilities qua link rates uit (de AP doet dat in z'n beacons, de STA in z'n association request). Je kunt bij wat geavanceerdere apparaten _{in dit lijstje alleen de UAP AC LIte} die lijst aanpassen. Voornaamste reden waarom je dat zou willen is om te zorgen dat je apparaten alleen verbinden als je daarmee een goed bruikbare verbinding krijgt. Immers, je hebt niets aan verbonden zijn met de ene AP met 1Mbps bruto (netto minder dan 500kbps, en dat geheid niet stabiel ) als je pal naast een andere AP staat. Eigenlijk heb je sowieso niets aan de laagste link rates voor normaal gebruik. Je ziet dat in enterprise-toepassingen standaard alles onder de 12Mbps vrijwel altijd gedisabled is en hogere waardes (alles onder de 24Mbps bijv) kom je ook vaak tegen.

Gevolg is dat je ofwel een fatsoenlijk bruikbare verbinding hebt met een AP, danwel geen verbinding. Komt bij dat het voorkomt dat devices met lage link rates de beschikbare airtime opsoepen - iemand met 6Mbps link rate, 4Mbps netto die een 3Mbps Netflix stream probeert te kijken vreet zomaar in z'n eentje met die ene stream 3/4 van de beschikbare airtime voor alle apparaten in dat kanaal op. Door minimaal 24Mbps verplicht te stellen zal diezelfde 3Mbps netto, 5Mbps bruto Netflix stream nooit meer dan zo'n 20% van de airtime vergen.

Maar goed, dit is bij roamingproblemen symptoombestrijding. Oorzaak is dat de client devices het niet als een netwerk zien.

pieterbeun schreef op zondag 22 juli 2018 @ 14:16:
[...]

Het netwerk heeft hezelfde SSID en zit in hetzelfde subnet (192.168.1.0). en gebruik het volgende:

Fritzbox 7560
Ubiquiti AP light
TP-link 1043.

Zelfde SSID en subnet zijn inderdaad twee van de vereisten voor roaming, maar er zijn er nog drie:
- zelfde PSK (wachtwoord)
- zelfde security (WPA2-only is iets anders dan WPA2/WPA!)
- zelfde encryption (CCMP(AES)-only is iets anders dan TKIP/CCMP(AES)!)

Niet helemaal verplicht maar wel erg handig: zelfde kanaalbreedte, met name in de 2.4GHz wil je alles op 20MHz breed hebben. O.a. TP-Link doet standaard "20/40MHz" maar pompt in praktijk 40MHz-only uit zonder correct werkende protection mechanism (oftewel terugschakelen naar 20MHz als er interferentie gedetecteerd wordt) Zet alles in de 2.4GHz op niet-overlappende kanalen (1, 6 of 11) van 20MHz breed.

Ik gok dat het op een van die laatste spaak loopt. Best practice: stel alles in op security WPA2-only en encryption CCMP(AES)-only. Goede kans dat het dan wel goed gaat.

Staat het al zo, of helpt het gelijkzetten niet? Dan heb je ws WiFi chipsetdrivers die roet in het eten gooien en dezelfde instelling in de GUI onder de motorkap (in de beacons) anders interpreteren. Alle apparaten die je noemt hebben (Qualcomm-)Atheros chipsets, dus kans hierop is kleiner dan het had gekund, maar is gezien de sterk uiteenlopende leeftijden van de apparaten wel aanwezig. In dat geval kun je spelen met de instellingen, Misschien dat AES/TKIP op alle apparaten wel goed werkt qua roaming. Let wel dat TKIP nogal ongewenst is (onveilig en traag) dus weeg - zeker bij andere problemen - de voordelen van roaming af tegen de nadelen van TKIP ingesteld hebben.

[Ben(V)]

Dus minimum data rates aanpassen kan eigenlijk alleen bij een UAP AC lite.
Dan zul je toch het vermogen moeten terugdraaien om betere roaming te krijgen als je andere AP's hebt.

[dion_b]

Ben(V) schreef op maandag 23 juli 2018 @ 15:15:
Dus minimum data rates aanpassen kan eigenlijk alleen bij een UAP AC lite.

Kan bij vrijwel alle enterprise-grade AP's en een zeer beperkte lijst consumentenspul, zoals de UniFi-reeks.

Dan zul je toch het vermogen moeten terugdraaien om betere roaming te krijgen als je andere AP's hebt.

Wederom, dit blijft symptoombestrijding. Moderne clients roamen uit zichzelf best goed. Doen ze dat niet, dan ligt het aan een verkeerde configuratie, hoogstwaarschijnlijk de beveilging/encryptie. Als je dat op orde hebt dan roamen apparaten vrijwel ongeacht radio settings.

[laurens0619]

Het is hierboven al uitgelegd maar plaatjes zeggen meer:

Situatie waar langzame linkrates aanstaan:


Situatie waar langzame linkrates uitstaan:


Situatie waar je minRSSI hebt ingesteld icm deauthenticatie:

Daarbij heb je ook nog de 2 smaken: "Stoppen met praten bij een minRSSI" en "Deauthenticate bij een minRSSI" waarbij de laatste de voorkeur heeft

@dion_b
Ik lees je analyse vaker terug dat roaming schijnbaar vaker misgaat omdat ze niet goed door de client als "roambaar netwerk" worden gezien.
Ik heb tot nu weinige andere bronnen gevonden waar ik meer hierover kan lezen, heb jij zo tips?

Verder vroeg ik mij af of je kunt meten/testen of je telefoon het als "roambaar" ziet. Ik heb ooit zelfs eens voor Windows een tooltje geschreven die de monitor/roaming state monitorde en daar was ook een event "roaming to another AP". Ik heb alleen geen idee hoe je vanuit iOS/Android kan testen of het netwerk goed gezien wordt. Of is het niet zo binair?

Je noemt trouwens een ander interessant punt in je post en dat is "moderne clients". We weten alleen niet van @pieterbeun welke devices hij gebruikt en of deze modern zijn, heb je daar meer info over @pieterbeun ?

[ Voor 5% gewijzigd door laurens0619 op 23-07-2018 22:04 ]

[dion_b]

laurens0619 schreef op maandag 23 juli 2018 @ 21:59:
[...]

Daarbij heb je ook nog de 2 smaken: "Stoppen met praten bij een minRSSI" en "Deauthenticate bij een minRSSI" waarbij de laatste de voorkeur heeft

Vergeet niet dat RSSI iets anders is dan link rate. Link rate is indirect een maat voor de SNR van de verbinding, dus verhouding tussen signaal en ruis. Dat bepaalt wat mogelijk is qua overdracht en is een goede indicatie voor de stabiliteit van de verbinding. RSSI is alleen het signaalniveau zonder rekening te houden met ruis. Als dat veel te laag is, is het sowieso brak, maar ook bij goede RSSI kun je slechte SNR hebben door veel ruis. Daarom vind ik RSSI een slechte maat voor signaalkwaliteit. Je moet ofwel een heel ruime marge nemen voor eventuele ruis - en dan veel te snel disconnecten waar het niet nodig is, dawel te weinig marge nemen en riskeren dat je nog verbonden blijft bij zoveel ruis dat je verbinding bagger is.

Zeker in de 2.4GHz is ruis een sinecure, dus wil je altijd rekening ermee houden. Link rates zijn de beste maat die je uit een standaarddriver krijgt voor bepalen daarvan.

@dion_b
Ik lees je analyse vaker terug dat roaming schijnbaar vaker misgaat omdat ze niet goed door de client als "roambaar netwerk" worden gezien.
Ik heb tot nu weinige andere bronnen gevonden waar ik meer hierover kan lezen, heb jij zo tips?

Het lastige met de meeste (semi) pro blogs die je in WiFi-land leest is dat ze gericht zijn op zakelijke netwerken, waar je een hele site voorziet van spullen van een enkele vendor en die vendor al >15 jaar zorgt voor identieke instellingen en >10 jaar in bijkomende features om roaming te helpen. Daar ga je inderdaad dat soort dingen niet teruglezen, want als je in die wereld aankomt met een beestenboel aan verschillende vendors, oud en nieuw door elkaar en geen enterprise roaming features kun je het vergeten

Uitzondering zijn de zeldzame stukken van certificeringslabs. Daar testen ze niet alleen enterprisespul, maar ook retailmeuk en providerapparaten. Daar vind je ook goede info terug, zie bijv dit artikel van Excentis:
https://www.excentis.com/blog/wi-fi-roaming-gotchas

Enige site dat beetje op de SOHO gericht is en structureel goed werk aflevert is smallnetbuilder.com - en ze hebben een zeer goed onderbouwde reeks over roaming, maar slaan (net zoals de meeste enterprise-blogs) het stukje over gelijke config niet alleen in UI maar ook in de beacons helemaal over

Wel leuk om te zien hoe je dit soort spul kunt testen:
https://www.smallnetbuild...-roaming-secrets-revealed
_{Ik heb een iets uitgebreidere setup dan hier beschreven om mee te werken, maar de principes zijn hetzelfde}

Verder vroeg ik mij af of je kunt meten/testen of je telefoon het als "roambaar" ziet. Ik heb ooit zelfs eens voor Windows een tooltje geschreven die de monitor/roaming state monitorde en daar was ook een event "roaming to another AP". Ik heb alleen geen idee hoe je vanuit iOS/Android kan testen of het netwerk goed gezien wordt. Of is het niet zo binair?

Pff, ik ben meer van de netwerken dan van de software. Volgens mij zou het erg simpel moeten zijn aangezien de meeste OSsen al een aggregatie doen van alle BSS'en die samen tot dezelfde ESS geacht worden te horen bij weergave - althans, ze gooien alle netwerken met zelfde naam op een hoop, maar misschien kijken ze al verder dan dat.

Enige echt foolproof manier die ik ken is naar de beacons kijken, en daarbinnen naar SSID (duh) en RSN (oftewel security) zaken. Let vooral op de Pairwise Cipher en Group Cipher. Als beide slechts één type (CCMP danwel TKIP) hebben, dan is het AES only danwel TKIP only. Lastige is dat je verschillende smaken kunt zien bij een mix - meestal verwacht ik dan bij pairwise beide te zien staan (AES en TKIP), maar bij Group een enkele (TKIP), maar het kan voorkomen dat je bij pairwise alleen AES ziet onder die omstandigheden. Dit soort verschil kan uitmaken of je wel of niet kunt roamen.

Je noemt trouwens een ander interessant punt in je post en dat is "moderne clients". We weten alleen niet van @pieterbeun welke devices hij gebruikt en of deze modern zijn, heb je daar meer info over @pieterbeun ?

Android ondersteunt roaming sinds 5.0, iOS sinds 8.nogwattes. MacOS al lang (maar ik weet niet exact hoe lang, ik geloof dat het bij 10.6 al werkte) en Windows... hangt zoals altijd af van de drivers van de gebruikte hardware

Zeker bij mobile devices moet je dus echt een hoogbejaard en/of low-end ding nodig hebben om geen goede roaming per default te kunnen.

[Plopeye]

Wat iedereen hier vergeet:

Roaming ga je met meerdere accesspoints van verschillende merken en zonder centrale controller nooit voor elkaar krijgen om de volgende reden:

De WPA auth doe je tegen het accesspoint, bij hoppen van de ene naar de andere accesspoint zal er dus een nieuwe authenticatie plaatsvinden en daarmee een disconnect en connect. Ook kan je het effect van hoppen krijgen als je net tussen 2 zenders in zit en er geen centrale controller is die dat een beetje stuurt.

De truuk van de centrale controller is dat de authenticatie tegen de controller gedaan wordt en dat de sessie die daarmee is opgebouwd over de verschillende zenders heen gaat. (Dus geen reconnect en reauth)

Heb je geen controller en meerdere accesspoints met dezelfde ssid en wpa sleutels dan kan je het hop effect krijgen wat dus een continu reeks van diconnect en reconnect tot gevolg heeft met en steeds een onderbroken datastroom.

[ijdod]

dion_b schreef op maandag 23 juli 2018 @ 23:20:
hangt zoals altijd af van de drivers van de gebruikte hardware

Zeker bij mobile devices moet je dus echt een hoogbejaard en/of low-end ding nodig hebben om geen goede roaming per default te kunnen.

Zoals de Samsung Xcover 4. Mocht iemand ooit zakelijk iets met mobiele devices gaan doen: zorg dat je duidelijke, en te testen, criteria hebt voor die devices, voordat ze aangeschaft worden...

Plopeye schreef op woensdag 25 juli 2018 @ 13:17:
Wat iedereen hier vergeet:

Roaming ga je met meerdere accesspoints van verschillende merken en zonder centrale controller nooit voor elkaar krijgen

Onzin. WPA2-PSK zit zo rond de 50ms, wat meer dan voldoende is. Ik ben het er mee eens dat een mix van consumer AP's erg lastig gaat worden, maar dat heeft meer te maken met het gebrek aan configureermogelijkheden om die dingen goed af te regelen te maken. APs van hetzelfde merk gaan echt niet magisch opeens beter roamen. Een mix van deugdelijke APs is beheersmatig niet handig, maar functioneel niet echt een belemmering.

Vergeet niet dat de pijn vooral in de enterprise omgeving zit waar je niet tegen een AP praat, maar tegen een hele keten (AP > Controller > Radius > AD). Dan wordt het opeens een heel ander verhaal, en worden allerlei trucs om dat proces te bespoedigen opeens heel erg belangrijk.

[Verwijderd]

De client zelf kiest toch het beste AP en doet de roaming? Bij mij wel iig.

[ Voor 12% gewijzigd door Verwijderd op 26-07-2018 19:30 . Reden: < ]

[Ben(V)]

Als je een professionele omgeving hebt zoals bijvoorbeeld een Aruba wifi netwerk dan is er een centrale controller in het wifi netwerk die het roamen regelt en niet meer het device.

Voor achtergrond info lees dit eens.
https://www.google.nl/url...Vaw2X_tQsvczoRSe2cTtpZdYL

[laurens0619]

Ben(V) schreef op donderdag 26 juli 2018 @ 19:36:
Als je een professionele omgeving hebt zoals bijvoorbeeld een Aruba wifi netwerk dan is er een centrale controller in het wifi netwerk die het roamen regelt en niet meer het device.

Voor achtergrond info lees dit eens.
https://www.google.nl/url...Vaw2X_tQsvczoRSe2cTtpZdYL

Ik heb het roaming stuk gelezen in het document maar kan alleen zaken terugvinden over fast roaming. Welke techiek zouden ze volgens jou gebruiken dan dat roaming niet meer bij de client ligt?

[Bastiaan V]

laurens0619 schreef op donderdag 26 juli 2018 @ 19:51:
[...]

Ik heb het roaming stuk gelezen in het document maar kan alleen zaken terugvinden over fast roaming. Welke techiek zouden ze volgens jou gebruiken dan dat roaming niet meer bij de client ligt?

Er zijn verschillende merken die "jouw" verbinding kunnen verplaatsen naar verschillende AP's (meestal radio's genoemd in een dergelijke omgeving).

Jouw device denkt dat hij met 1 AP verbonden terwijl deze connectie met jou meeloopt van radio naar radio.
Hier is vaal al geen centrale controller meer voor nodig. Natuurlijk moet er wel een samespel tussen de radio's / AP's zijn (Ruckus heeft bijvoorbeeld de unleashed serie).

[laurens0619]

Bastiaan V schreef op donderdag 26 juli 2018 @ 23:35:
[...]


Er zijn verschillende merken die "jouw" verbinding kunnen verplaatsen naar verschillende AP's (meestal radio's genoemd in een dergelijke omgeving).

Jouw device denkt dat hij met 1 AP verbonden terwijl deze connectie met jou meeloopt van radio naar radio.
Hier is vaal al geen centrale controller meer voor nodig. Natuurlijk moet er wel een samespel tussen de radio's / AP's zijn (Ruckus heeft bijvoorbeeld de unleashed serie).

Interessant, is dat vergelilbaar met de “zero handoff” die unifi hanteerde?
In praktijk heb ik de setup niet vaak gezien omdat alle ap’s op 1 kanaal ook erg kan storen . Naast de “l1” aanpak zou ik technisch graag willen begrijpen wat de enterprise technieken anders doen. Als ik lees bv wat “smartroam” is bij ruckus komt dat gewoon weer neer op een minrssi deauth: https://support.ruckuswireless.com/answers/000002277

[Plopeye]

Onzin. WPA2-PSK zit zo rond de 50ms, wat meer dan voldoende is.

Die 50ms haal je niet met consumer grade accesspoints, en daarbij het blijft een disconnect / reconnect.
Ook de sturing van wanneer te hoppen ontbreekt, het hangt volledig af van de client want de zenders weten van elkaar niet wat ze doen.

Boven op de reconnect komt ook nog eens een DHCP request (Het antwoord is dan waarschijnlijk dat hij zijn lease mag blijven gebruiken, maar na een disconnect doet een device dit wel) en het opnieuw advertisen van het MAC adres naar de ARP/MAC table van je router/switch. Ook dit kost allemaal tijd, het is dus niet enkel de reconnect/ reauth maar nog een domino aan vervolgprocessen.

Wat er gebeurt op het moment dat je contact maakt met een accesspoint die zelf de authentication doet:

1. Authentication (client)

2. Authentication Response (AP)

3. (Re)Association Request (client)

4. (Re)Association Response (AP)

WPA2 Enterprise 802.1X/EAP (client, AP, and authentication server); skipped in WPA2 Personal

5. Four-way handshake #1 – AP nonce passed to client (AP)

6. Four-way handshake #2 – Supplicant nonce passed to AP(client)

6.5 Derivation of encryption key (AP & Client independently)

7. Four-way handshake #3 – verification of derived encryption key and communication of group transient key (AP)

8. Four-way handshake #4 – acknowledgement of successful decryption (client)


Wat er gebeurt als je contact maakt met een fatsoenlijk wifi netwerk met controller:

1. Authentication (client)

2. Authentication Response (Controller)

3. (Re)Association Request (client)

4. (Re)Association Response (Controller)

WPA2 Enterprise 802.1X/EAP (client, AP, and authentication server); skipped in WPA2 Personal

5. Four-way handshake #1 – AP nonce passed to client (Controller)

6. Four-way handshake #2 – Supplicant nonce passed to Controller(client)

6.5 Derivation of encryption key (Controller & Client independently)

7. Four-way handshake #3 – verification of derived encryption key and communication of group transient key (Controller)

8. Four-way handshake #4 – acknowledgement of successful decryption (client)

Bij het hoppen van de ene zender naar de andere hoeft dit proces dus niet opnieuw, want de sessie data en afgesproken encryptiesleutels reizen mee van de ene zender naar de andere via de centrale controller.
Daarnaast heeft de controller zicht op wie op welke zender zit en kan ook even het laatste zetje geven aan een client om over te hoppen, niet alle devices gaan even goed om met roaming namelijk.

Voor de TS kan het al zo simpel zijn als wifi op de fritzbox uit, de TP-Link het raam uit en een Ubiquiti Unifi Cloudkey + extra Unifi AP's waar nodig bij kopen.
Tip: De Unifi AP AC Pro, ja hij is wat duurder maar de performance en dekking is behoorlijk ok.
Maar je kan ook elk andere unifi AP kiezen, welke dan ook maar past bij de behoefte/budget.

De cloudkey is een minicomputer waar de Unifi software op draait en functioneert op die manier als centrale controller. Let op! heb je een synology nas dan is het verstandig om dit even te lezen voordat je een cloudkey koopt:
http://synology.acmenet.ru/

Ja ik weet het, .ru maar in dit geval nog geen rotte zooi getroffen via die weg.

[laurens0619]

Plopeye schreef op vrijdag 27 juli 2018 @ 08:52:
[...]


Die 50ms haal je niet met consumer grade accesspoints, en daarbij het blijft een disconnect / reconnect.
Ook de sturing van wanneer te hoppen ontbreekt, het hangt volledig af van de client want de zenders weten van elkaar niet wat ze doen.

Dat zijn 2 verschillende onderdelen, je hebt:
1. De afweging en actie om te roamen
2. De tijdsduur dat het daadwerkelijke roamen duurt (volgt na 1)

Hetgeen wat jij beschrijf met authenticatie/dhcp heeft alleen betrekking op de tijdsduur, het is en zal een disconnect/reconnect naar ap blijven.
De tijdsduur is vooral interessant als er voip achtige zaken over het wifi gedaan wordt en clients zich veel bewegen. De meeste mensen lopen echter tegen probleem 1 aan (zoals ook in dit topic) en daar gaat 802.11r/fast roaming geen verschil in maken.

[ijdod]

Bastiaan V schreef op donderdag 26 juli 2018 @ 23:35:
[...]


Er zijn verschillende merken die "jouw" verbinding kunnen verplaatsen naar verschillende AP's (meestal radio's genoemd in een dergelijke omgeving).

Een Single Channel Architecture lost daarmee inderdaad het roaming probleem op, omdat je client niet meer hoeft te roamen. Er zijn een aantal merken die dat doen, maar het is geen echt schaalbare oplossing, doordat alles op een enkel kanaal zit. Er is een reden waarom je dit zelden toegepast ziet. Het is geen techniek voor algemeen gebruik, maar een specifieke oplossing voor een specifiek probleem; waarbij de voordelen belangrijker moeten zijn dan de nadelen. Voor het merendeel van wifi is dat niet het geval.

Buiten dit doen controllers uiteindelijk niet veel meer dan het wegpesten van clients in de hoop dat die dan het juiste ding doen en daadwerkelijk roamen.

@laurens0619 Ubiquiti Zero Handoff zit in die hoek, inderdaad.

laurens0619 schreef op vrijdag 27 juli 2018 @ 09:43:
Hetgeen wat jij beschrijf met authenticatie/dhcp heeft alleen betrekking op de tijdsduur, het is en zal een disconnect/reconnect naar ap blijven.
De tijdsduur is vooral interessant als er voip achtige zaken over het wifi gedaan wordt en clients zich veel bewegen. De meeste mensen lopen echter tegen probleem 1 aan (zoals ook in dit topic) en daar gaat 802.11r/fast roaming geen verschil in maken.

Dit is de kern van het verhaal inderdaad. Als naadloos roamen een vereiste is, dan moet je beginnen je RF dekking op orde te hebben, en afgestemd op je meest kritische devices. Die laatste zal je ook daadwerkelijk moeten beheren (dus testen, configureren, enzovoorts). Die laatste stap is het belangrijkst, en het moeilijkst.

@Plopeye Wat er met DHCP gebeurt is ook weer iets wat per client verschilt, en is geen reden voor een onderbreking. (of beter: als het dat wel is, gaat roamen sowieso een dingetje zijn op dat device)

[Plopeye]

@ijdod de reden voor onderbreken is er dus wel als je losse accesspoints hebt. Je layer2 connectie gaat namelijk down en er vindt een nieuwe handshake plaats. (Hetzelfde effect als je utp kabel uit een netwerkkaart trekken en weer terugstoppen)
Dat is nou net het verschil tussen losse accesspoints en een netwerk met controller waarbij de accesspoints slechts een radio zijn en de handshake met de controller plaatsvind.

[ Voor 11% gewijzigd door Plopeye op 28-07-2018 19:43 ]

[dion_b]

Plopeye schreef op vrijdag 27 juli 2018 @ 08:52:
[...]


Die 50ms haal je niet met consumer grade accesspoints, en daarbij het blijft een disconnect / reconnect.
Ook de sturing van wanneer te hoppen ontbreekt, het hangt volledig af van de client want de zenders weten van elkaar niet wat ze doen.

Correct. Maar dat boeit bijzonder weinig tenzij je VOIP doet. Het gaat erom *dat* de client besluit te roamen. Hoe snel dat gebeurt is van ondergeschikt belang. Pas als je dat op orde hebt begint het interessant te worden hoe snel dat gaat.

[...]

De cloudkey is een minicomputer waar de Unifi software op draait en functioneert op die manier als centrale controller.

Nee.

De UniFi "controller" is helemaal geen controller in die zin, het doet alleen management (beheer van instellingen) en evt walled garden/landing page. Daadwerkelijke roaming is nog steeds overgeleverd aan de clients.

Waarom werkt het dan zo goed? Omdat de instellingen identiek zijn waardoor een competente client goed z'n werk kan doen. Meer niet.

_{En "minicomputer"... Zoek eens op definitie daarvan en/of foto's van een VAX...}

[ Voor 4% gewijzigd door dion_b op 28-07-2018 20:26 ]

[Plopeye]

@dion_b lees ook dit eens:

https://help.ubnt.com/hc/...662107-UniFi-Fast-Roaming

Daarnaast kent ook unifi zero-handoff (vereist ook single frequency om in te schakelen)
Nadeel van een single frequency network is dat het gehele netwerk dezelfde tijdslots moet delen. (Wifi is TDM)

Unifi zal vast en zeker iets simpeler zijn dan bijvoorbeeld een ruckus systeem, maar de tijd dat hij enkel instellingen deed is voorbij.

[ Voor 7% gewijzigd door Plopeye op 29-07-2018 08:06 ]

[ijdod]

@Plopeye
Unifi gebruikt de controller niet tijdens fast roaming. Het is ook geen feature die standaard aan staat, overigens. Zero-Handoff is Unifi van afgestapt.

[ Voor 10% gewijzigd door ijdod op 29-07-2018 08:42 ]

[dion_b]

Plopeye schreef op zondag 29 juli 2018 @ 08:04:
@dion_b lees ook dit eens:

https://help.ubnt.com/hc/...662107-UniFi-Fast-Roaming

Zoals hierboven al geroepen werkt Ubnt's Fast Roaming sowieso buiten de controller om. Maar fundamenteler nog: het is weer een techniek om sneller te roamen dat niets bijdraagt aan de daadwerkelijke keuze (van de client!) *om* te roamen.

Daarnaast kent ook unifi zero-handoff (vereist ook single frequency om in te schakelen)
Nadeel van een single frequency network is dat het gehele netwerk dezelfde tijdslots moet delen. (Wifi is TDM)

Zero Handoff is deprecated, niet meer ondersteund sinds de introductie van de ac-reeks van UAP's, en daarvoor ook nooit het beta-stadium ontgroeid. Het (single channel architecture) is een leuk - maar in de meeste gevallen hopeloos inefficiënt - concept dat in heel specifieke situaties flinke meerwaarde kan bieden (Meru verdient er goed geld mee) , maar het stelt hoge eisen aan de hardware en aan de kennis van degene die het implementeert.

En sowieso - ook ZH maakte geen gebruik van de Ubiquiti 'controller' maar wordt door de AP's onderling geregeld.

Unifi zal vast en zeker iets simpeler zijn dan bijvoorbeeld een ruckus systeem, maar de tijd dat hij enkel instellingen deed is voorbij.

Nee dus. De UniFi controller is echt niet meer dan een lokale variant op een cloud webui. Alle daadwerkelijke real-time acties in een UniFi-netwerk doen de AP's zonder interactie met de controller. Dat is simpel aan te tonen: trek de stekker uit de controller. Enige wat je kwijt raakt is een evt landing page. Roaming gaat net zo goed of slecht als voorheen.

[Plopeye]

Ik hen het hier thuis getest en ben toch tot de conclusie gekomen dat roamen inderdaad nog gaat als de controller down is. Wel duurt het op dat moment langer tussen disconnect en reconnect. Ik zou een capture moeten doen om te zien wat er aan communicatie plaatsvind in beide gevallen maar het lijkt er toch op dat indien de controller wel live is dat de handover sneller verloopt. Ik heb hier de laatste versie van unifi met de laatst beschikbare firmware’s draaien.

Ook heb ik gemerkt dat met name iOS devices er meer moeite mee hebben dan een android of windows machine.

[hneel]

dion_b schreef op maandag 23 juli 2018 @ 12:00:
[...]
Zelfde SSID en subnet zijn inderdaad twee van de vereisten voor roaming, maar er zijn er nog drie:
- zelfde PSK (wachtwoord)
- zelfde security (WPA2-only is iets anders dan WPA2/WPA!)
- zelfde encryption (CCMP(AES)-only is iets anders dan TKIP/CCMP(AES)!)

Bedankt!
Ik kreeg die roaming hier thuis ook nooit goed voor elkaar. Wachtwoord had ik uiteraard wel overal hetzelfde, maar die laatste 2 dingen die je noemt had ik nog nooit ergens anders gelezen. Nu heb ik dat overal gelijk ingesteld en het lijkt nu op het eerste gezicht te werken.

[ Voor 5% gewijzigd door hneel op 29-08-2020 17:55 ]