W dniu 2019-10-14 o 15:16, viktorius pisze:
> W dniu 2019-10-14 o 13:26, Adam pisze:
>> W dniu 2019-10-14 o 12:54, viktorius pisze:
>>> W dniu 2019-10-14 o 11:54, Marek pisze:
>>>> On Mon, 14 Oct 2019 11:19:00 +0200, sirapacz <n...@s...pl> wrote:
>>>>> Poszukaj informacji o wifi mesh
>>>>
>>>> O ile wiem mesh dot. sytuacji w których AP nie mają dostępu do sieci
>>>> i ramki przekazują między sobą. To inna sytuacja, tutaj AP mają
>>>> dostęp do tego samego segmentu sieci. Adresy IP przydziela jeden
>>>> serwer dhcpd a nie AP.
>>>
>>> Mesh może być w topologii bezprzewodowej, jak i kablowej. To nie
>>> powinno mieć znaczenia.
>>>
>>>> Mi chodzi o uzyskanie efektu wyboru silniejszego AP i żeby
>>>> przelaczenie nie wpływało na aktywne sesje tcpip (stąd centralny
>>>> dhcpd). To działa z tym że zauważyłem, że klient często męczy się
>>>> przyłączony do słabego AP gdy w przeglądaniu sieci widać inny
>>>> silniejszy. Mam wrażenie że to przełączanie jest po utracie zasięgu
>>>> a nie przed.
>>>>
>>>
>>> To również ma robić mesh. To już nie twoja sieciówka w telefonie
>>> decyduje o przełączeniu miedzy APkami, tylko cały mesh monitoruje
>>> siec i nakazuje twojej sieciówce przełączenie "póki nie jest za późno".
>>> Dzięki temu poziom sygnału ma być optymalny, a samo przełączenie ma
>>> się tak zrobić, żebyś nie stracił za dużo pakietów. Skype, Youtube
>>> czy inne streamy mają się nie zaciąć, nie stracić klatki.
>>>
>>> Sęk w tym, że mesh pomimo, ze jest zdefiniowany w IEEE 802.11s, to
>>> jest implementowany przez producentów zawsze troche "po swojemu".
>>> Teraz jest tak, jak w poczatkach 802.11g. Jak trzymasz się jednego
>>> producenta to jakoś tam chodzi, ale osiwiejesz zanim uda ci się zgrać
>>> w meshu urządzenia różnych producentów.
>>>
>>
>> Ciekawe z tym mesh.
>>
>> Jakoś tak od 802.11b instalowałem sieci w dużych halach (Auchan, Ikea,
>> itp) oraz w zakładach na dużym terenie (kilkanaście budynków, parkingi
>> i ścieżki dla widlaków).
>> Wszędzie było to samo SSID. Ramki nie mogły się gubić, bo aplikacje na
>> terminalach (wtedy) dość szybko zgłaszały błąd. Podobnie, kilka
>> zgubionych ramek mogło powodować brak wydruku na drukarce mobilnej
>> etykiet. Terminale były na WinCE Core lub WinCE Mobile.
>>
>
> Ale to był mesh, czy sieć niezaleznie działających APków z tym samym
> SSIDem? Jakie było szyfrowanie (jeśli było w ogóle)?
> Jak dla mnie to hosty przełączały się samoczynnie. Pakiety się traciły,
> ale tylko dzięki retransmisji na poziomie warstwy 1 miałeś połączenie.
> Taki pakiet TCP nie zdążył wypaść (a to pewnie monitorowały terminale),
> ale pod spodem pewnie było kilkanaście prób retransmisji.

Muszę zobaczyć do materiałów.
Najczęściej kładło się AP-Switch a do niego albo wiele AP albo tylko
szeroko rozmieszczone anteny na długich kablach. AP-Switche dogadywały
się między sobą.
Był to sprzęt m.in. Motoroli, Cisco (tego prawdziwego) i Symbola.
Niestety, nie programowałem tego. Natomiast testery sieci wykazywały
albo zupełny brak zgubionych ramek, albo na poziomie pojedynczych.
Natomiast nie wiem, co przełączało - czy sieć wymuszała, czy klient.
Ja zajmowałem się pomiarami sygnału, programowaniem czytników cen dla
klientów na halach sklepowych i programowaniem terminali oraz drukarek
mobilnych dla obsługi.

>
> W meshu klient jest sterowany. Przy jednakowej sile sygnału ma się
> połączyć z APkiem, który zapewnia np. mniej hopów, albo jest w danym
> momencie mniej obciążony transferem (a niekoniecznie jest najsilniejszy
> sygnałem). W efekcie taki klient dostanie się do lekko słabszego
> sygnałem APka, ale w danej chwili dającego większą przepustowość.
>
>> Co się popsuło, aktualnie jest problem z urządzeniami różnych
>> producentów?
>>
> Bo oprócz wspieranie wprost standardu, producenci dodają swoje
> "optymalizacje" i w efekcie mesh najlepiej działa "swój ze swoim", a nie
> "swój z obcym" gdzie ograniczamy się tylko do komunikatów określonych w
> IEEE
>

Czyli analogicznie, jak w początkach 802.11n (802.11n draft).


--
Pozdrawiam.

Adam