wifi - handover bez notyfikacji zmiany AP

Czy istnieje jakaś implementacja/hardware, która umożliwia klientom typu telefon (jakim?) przełączanie między poszczególnymi AP na dużym terenie ale by klient (telefon) nie generował u siebie zdarzeń rozlaczanie-podlaczanie do nowego AP? Cos co z pkt widzenia klienta było jedną wielką siecią wifi bez zmiany AP? Każde przełączanie AP (nawet o takim samym ssid) u klienta powoduje zakłócenie działania pewnej aplikacji bo aplikacja odbiera soft broadcast zdarzeń wifi (nie mylić z broadcastem w sieci). Nawet bardzo szybkie przełączanie między AP niestety generuje to zdarzenie.

Reply to
Marek
Loading thread data ...

W dniu 2020-05-27 o 09:54, Marek pisze:

AP Switch, Mesh itp rozwiązania.

Reply to
Adam

Mesh? Przecież Mesh to technika przekazywania danych między AP co to ma wspólnego ze handoverem klienta?

Tego co czytam AP Zwitxh nadal jest to oparte na przelqczaniu AP unklienta, czyki klient widzi zmianę AP, jest widoczna operacja "odlacz od starego- przyłącz do nowego" a ma być to niewidoczne dla API

Reply to
Marek

np urządzenia obsługujące UniFi jak Ubiquity

ale klienci muszą wspomagać 802.11r

Reply to
Cezar

Nie wiem dokładnie, co robi klient, na niskim poziomie tego nie sprawdzałem.

Ale tak instalowałem w dużych halach typu Ikea, Auchan, Leroy, gdzie punktów AP jest kilkadziesiąt czy kilkaset. Instalowałem też sieci w firmach na dużym terenie. Niektóre aplikacje (zwłaszcza hamerukaćskie albo brytyjskie) były bardzo podatne na ucieczkę pakietów. Nie było problemów, nic się nie gubiło, klienty przełączały się płynnie na poszczególne punkty AP. W testach nic nie ginęło, ani jeden pakiet. Testy były robione na urządzeniach z windowsami CE, Mobile, WinXP, Win7.

Reply to
Adam

Wg informacji nadal jest to przełączanie AP więc api wykryje zmianę AP, a ma być przeźroczyste, da się tak w ogóle? Nie chodzi mi o to jak kolega Adam pisał, że przełączanie jest bez start pakietu w warstwie IP, chodzi o to by API nie "widziało" zmiany AP bo to zdarzenie psuje działanie aplikacji.

Reply to
Marek

No to nie używać UDP.

formatting link
formatting link
Pzdr.

Adam Górski

Reply to
Adam Górski

Problem nie jest w warstwie IP tylko w API wifi Androida, które do aplikacji broadcastuje stan "wifi się przełącza/zmienia AP".

Reply to
Marek

No raczej się nie da bo z założenia po przełączeniu do innego AP ponownie musi być pobrany IP z DHCP , DNS, gateway etc bo może być już inny. Zapewne mogę się mylić.

Zobacz tutaj:

formatting link
Adam

Reply to
Adam Górski

Nic nie musi. Sieć wi-fi nie ma nic wspólnego z IP - to nie ta warstwa. System dla "wygody" użytkownika odnawia adresy, ale przecież nie musi tego robić, a jeśli jest uparty, to można ustawić statyczne.

Reply to
Mirek

Motorola miała lat temu kilkanaście takie wynalazki: coś w rodzaju AP i do niego podpiętych wiele anten na długich kablach. Ale te kable to też raptem kilkadziesiąt metrów max. Szczegółów nie pamiętam, a poza tym to i tak nie pasuje do Twojego dużego terenu.

Nie wiem, czy w przypadku AP Switch nie jest tak, że sieć jest "jednolita" w ten sposób, że poszczególne AP są nierozróżnialne przez klienta. Ale takie AP-switche kosztowały po kilka tys. dolarów i to był standard tylko 802.11g.

Reply to
Adam

Łatanie czyjejś fuszerki czy obchodzenie celowych ograniczeń? Proponuję zestaw klient-AP noszony razem z telefonem. Telefon połączony z AP stale a klient niech się przełącza. W razie czego jeszcze NAT po drodze.

Reply to
Mirek

A co Twoim zdaniem system powinien zrobić jak znika połączenie ? A zanika na nieznany czas - czas potrzebny na przełączenie.

To aplikacja jest problemem a nie system.

Pzdr.

Adam

Reply to
Adam Górski

Ale to jest coś zupełnie innego niż sieć zarządzana przez kontroler (nawet jeżeli jest nim jeden z AP). Natomiast urządzenie wie, że jest przełączane pod inny AP (w końcu też w tym uczestniczy), pomimo że SSID jest ten sam. Zupełnie inna sprawa czy aplikacja potrafi z tym żyć. I same urządzenia też muszą potrafić z tego korzystać. teraz już nie sprawdzę czy dzierżawa była odświeżana, ale zdaje mi się że urządzenie wie że ma się przełączyć pod określonego AP, a reszta jest stała. Przy próbie przejścia z jednego do drugiego AP pracującego z kontrolerem czasem mi wcinało pinga na moment (jeden, dwa pakiety, i to nieregularnie, czasem na pingu nie widać było zmian, ale też miejsce takie że zasięg ze wszystkich AP był kiepski). Czy to wystarczy aplikacji która reaguje tak albo inaczej na takie zdarzenia to już sprawa aplikacji. Testy robiłem na CAPach Mikrotika, ale ogólnie na podobnych urządzeniach innych firm działało to podobnie. Zupełnie inna sprawa kiedy mowa o tzw repeaterach WiFi - to działa, powiedzmy, tak sobie.

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

Tak, stąd moje pytanie jak np. w praktyce działa implementacja

802.11r, czy robi to na tyle przezroczyście dla API, że nie ma zdarzenia p.t. "zmiana AP", którego durna aplikacja zobaczy. Oczywiście sytuacja skrajna czyli przejście z zasięgu jednego AP do drugiego przez dziurę w zasięgu nie wchodzi w grę. Założenie jest, że pokrycie jest na odpowiednią zakładkę.
Reply to
Marek

No właśnie czy reapeater jest takim dodatowym AP do którego trzeba się przełączyć czy po prostu jest na tym samym paśmie (co w konsekwencji je ogranicza przepustowo) i klient jedynie widzi skok w sile sygnału tego samego AP?

Reply to
Marek

Jak ma stały adres? Czekać. Jak ma dynamiczny, to krótki zanik połączenia kablowego czy wifi też nie powinien być pretekstem do natychmiastowego słania prośby o nowy adres.

Ale to są milisekundy, najwyżej pojedyncze sekundy.

Zgadzam się, ale nie wiemy do czego ta aplikacja ma służyć. Być może nikt nie zakładał pracy na wifi.

Reply to
Mirek

W dniu 2020-05-28 o 19:28, Marek pisze:

Może tak - repeatery były znane od lat i pomimo prostoty implementacji nie przyjęły się jakoś. Masz klienta widzącego oba AP (nie da się inaczej) który się pyta do którego AP ma się podłączyć podając dwa razy ten sam SSID... Albo sam decyduje, a po rozłączeniu (z powodu utraty łączności, bo dopóki ma to trzyma) łączy się na nowo z tym co zobaczy. A bywa że twierdzi że to nie ten sam i musisz wpisywać dane do łączenia na nowo. Ale ogólnie zależy to mocno od systemu. Co innego sieć z kontrolerem - tam można sobie zaszaleć i np ustawić progi mocy przy których ma nastąpić przełączenie na kolejny AP, chociaż producenci dają różne możliwości konfiguracji. Ja zadowoliłbym się mikrotikiem gdyby nie to że nie udało mi się skonfigurować Wifi tak żeby mieć wszystko co chciałem, czyli CAP i wskazany zewnętrzny serwer radius. Plus takie tam drobiazgi typu sieć dla gości ze zmiennym hasłem. Z osobna każda z tych funkcjonalności tak, ale razem to już nie. Chociaż nie pamiętam czy rzeczywiście serwer radiusa udało mi się wskazać czy musiał być na mikrotiku. Przymierzam się trochę do sprawdzenia tego ubiquiti czy jak mu tam, ale to już trochę większa kasa na urządzenia - wydanie na testy to już niekoniecznie łatwo, a jakoś nie mam takiego ciśnienia żeby kolejny tydzień wyrwać na te testy. W każdym razie ustawienia CAP i samodzielnego AP to inna bajka.

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

No właśnie tutaj są dla mnie niejasności. W howto dot. roamingu/hamdoveeu producemci urządzeń często powtarzają i podkreślają, że przełączenie między AP to _zawsze_ decyzja klienta i z reguły właśnie jest tak, że klient trzyma ciągle z dalszym i słabszym AP zamiast przełączyć się na bliższy i mocniejszy. Stąd jak kontroler "zmusza" klienta, skoro to i tak on podejmuje decyzję o wyborze?

Reply to
Marek

Wifi calling plusa :-) Ponieważ służy wyłącznie do używania na wifi, każde przełączenie (zmiana) uznaje jako chwilowe utracenie połączenia wifi, przez co loguje telefon z powrotem przez GSM. Efekt tego jest taki, że jeśli przełączenie wifi nastąpi podczas trwającej rozmowy to po chamsku przerywa połączenie. W sieci wifi w jakiej to używam jest jeden serwer DHCP dla wszystkich klientów/AP, wiec zmiana AP w kliencie nie zmienia adresacji. Ale nie sprawdziłem jeszcze jak w szczególe API Androida zachowuje się w takich sytuacjach i czy np. nie wywala sieci na moment przełączenia by ponownie odświeżyć (na to samo IP). Ale taki chwilowy brak sieci dla źle napisanej aplikacji może być problematyczny.

Reply to
Marek

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.