Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

линукс учебник

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: [Lug-bg] OpenWrt auto migration


  • Subject: Re: [Lug-bg] OpenWrt auto migration
  • From: Marian Marinov <mm@xxxxxxxx>
  • Date: Thu, 10 Nov 2016 21:21:26 +0200

Петко, разкажи, какво направи за openfest и до колко това е помогнало за по-добрият wifi.

Мариян

On 11/10/2016 08:23 PM, Yordan Georgiev wrote:
Здравейте,

Някой да е стинал до решение? Или задълбочени тестове за по-голяма насока?

Данчо.

2016-08-24 12:37 GMT+03:00 Svilen Ivanov <svilen.ivanov@xxxxxxxxx <mailto:svilen.ivanov@xxxxxxxxx>>:

    Съжалявам за спама, исках да отговоря директно на Петко


    On Wednesday, 24 August 2016, Svilen Ivanov <svilen.ivanov@xxxxxxxxx <mailto:svilen.ivanov@xxxxxxxxx>> wrote:

        Respec!!!

        On Tuesday, 23 August 2016, Petko Bordjukov <bordjukov@xxxxxxxxx> wrote:

            Утро,

            1. Въведение

            1.1. Ключови думи

            Терминологията, която ще използвам, е следната:

            * STA (станция) – клиент на дадена безжична мрежа.
            * BSS (basic service set), базово множество услуги – точка за достъп и всичките
              ѝ клиенти.
            * ESS (extended service set, разширено множество услуги) – няколко BSS-а,
              свързани чрез система за дистрибуция.
            * DS (distribution system, система за дистрибуция) – системата, чрез която
              множество BSS-и са свързани в един ESS. Ще подразбирам Ethernet сегмент.
            * Roaming (роуминг) – преминаване от един към друг BSS в един и същи ESS.
            * Client steering (насочване на клиенти) – активно действие от страна на точка
              за достъп, което кара клиент да се асоциира с определен BSS.
            * Band steering (насочване към честотна лента) – като client steering, само че
              насочва клиента към BSS в по-предпочитана честотна лента.

            1.2. Стандартизация

            IEEE 802.11 стандартите изрично отбягват специфицирането на „настойчиви“
            действия и логика от страна на точките за достъп, що се отнася за насочване на
            клиентите. С други думи, когато се говори за избор на BSS, с който да се
            асоциира, топката е ИЗЦЯЛО в ръцете на STA имплементациите. Отказ от асоциация,
            на базата на друго, освен липса на правомощия за асоциация, е в разрез със
            стандартите.

            Поправки на IEEE 802.11 с отношение към роуминг и насочване на клиенти – IEEE
            802.11f (нестандартизиран), IEEE 802.11r, IEEE 802.11k, IEEE 802.11v, IEEE
            802.11ad.

            2. Съществуващи имплементации на насочване на клиенти

            2.1. Решения със затворен код

            Въпреки 1.2, почти всеки сериозен производител на Wi-Fi хардуер, има собствена
            имплементация на client и band steering. Няма да навлизам в детайли за Cisco,
            Aruba, UBNT, защото имплементациите им са затворени и нямам наблюдения над тях,
            освен за съществуването им.

            2.2. hostapd

            В де-факто стандартната имплементация на точка за достъп за Linux съществуват
            имплементирани както стандартизирани, така и нестандартизирани методи за
            насочване на клиенти.

            2.2.1. Нестандартизирани подходи за насочване към честотна лента в официалните
                   версии на hostapd

            hostapd поддържа два подхода за насочване към честотна лента – отказ от отговор
            на probe request, ако даден клиент е бил забелязан на интерфейс в 5 ГХц честотна
            лента, или отказ от асоциация при същото условие[1]. И двата са доста
            „непохватни“, защото не взимат предвид това дали клиентът не би имал проблем при
            свързването към BSS-а на другия банд.

            Важно е да се отбележи, че гореспоменатите два подхода могат да бъдат използвани
            само в случай, че една и съща инстанция на hostapd управлява всички физически
            интерфейси. Това е в разрез с текущата имплементация в OpenWrt и LEDE, при която
            за всеки физически интерфейс се стартира отделна инстанция на hostapd. Въпросът
            за изоставяне на сегашната имплементация беше отхвърлен от разработчиците на
            LEDE, защото би изискал сериозни промени в LEDE и ще направи системата по-малко
            отказоустойчива – при проблем с hostapd на един интерфейс, ще спре и другия.

            Също така, не е имплементиран начин споменатите в [1] таблици от съседи да бъдат
            споделяни между отдалечени инстанции на hostapd. Това прави описаните в [1]
            подходи неприложими или поне непредвидими, при използване на повече от едно
            устройство в един ESS.

            2.2.2. Нестандартизиран подход за насочване към честотна лента във форка на
                     hostapd на Google

            В доста информативна лекция по темата[2], служител на Google представи собствената
            им интелигентна имплементация[3] на band steering.

            Плюсовете на тази имплементация пред вече съществуващата в hostapd са:

              * Взима предвид потенциални проблеми при свързване към BSS-а на 5 ГХц.
              * Предвидена е да бъде използвана в сценарий, при който отделна инстанция на
                hostapd управлява всяки отделен физически интерфейс.

            За съжаление обаче е неизползваема в контекста на ESS с повече от една точка за
            достъп на отделни устройства.

            Бих бил много щастлив, ако някой се заеме и имплементира дистрибутиран списък с
            клиенти, с който да работи тази имплементация. Нужна ни е за Open Fest.

            2.2.3. Насочване към честотна лента чрез специфицираните в IEEE 802.11ad
                     инструменти

            IEEE 802.11ad въвежда промени, чиято цел е да улеснят избора на правилния банд
            от клиенти. В повече детайли – въвежда се MB (като multi-band) информационен
            елемент в beacon фреймовете на BSS-ите и метод за бързо прехвърляне на клиентска
            сесия между отделни BSS-и. В hostapd и wpa_supplicant от относително скоро
            съществува имплементация и за двете, но е скрита за конфигурационен флаг[4].

            Положителното на тази имплементация е, че е стандартизирана от IEEE, но носи и
            редица отрицателни характеристики:

              * Изисква поддръжка от клиентска страна.
              * Нужно е една инстанция на hostapd да управлява всички физически интерфейси
                (като при 2.2.1).
              * Нова е, неистествана е и преди всичко – не е активирана по подразбиране.

            2.2.4. Насочване на клиентите чрез средствата на IEEE 802.11r, k и v.

            От Cisco са описали по същество що е то Assisted Roaming чрез използването на
            горните стандарти[5]. Препоръчвам да прочетете статията за детайли. Обобщено
            обаче, идеята зад методите за улесняване на решенията за роуминг зад тези
            поправки, е следната:

            Точките за достъп събират информация за използването на радио ефира както от
            станциите в обхвата им, така и на база на собствените си наблюдения. Тези данни
            се предоставят на всяка станция и се очаква имплементацията на всяка станция да
            вземе решение към кой BSS да се асоциира.

            В hostapd и wpa_supplicant изглежда съществуват поне частични
            имплементации[6]. Предстои да ги проуча и тествам преди Open Fest.

            Огромният недостатък е, че е нужно клиентите да имплементират дадената логика за
            избор на BSS.

            2.2.5. Насочване на клиентите чрез ограничаване на мощността на излъчване на
                   мрежовите карти на точките за достъп и избор на кодировки за висока
                   производителност

            Най-изпитаният и най-широко съвместим метод за „поощряване“ на клиентите да
            преминат към друг BSS остава внимателното избиране на подходяща мощност на
            излъчване от страна на точките за достъп. Това, комбинирано с ограничаването на
            basic rate-овете до 54Mbps исторически винаги е работило доста добре на Open
            Fest[9].

            3. Особености при роуминг

            При преминаване от един BSS към друг в контекста на един и същи Ethernet
            сегмент съществуват няколко особености, за които трябва да бъдат взети мерки.

            3.1. Обновяване на кеша на L2 устройствата в Ethernet сегмента

            Две точки за достъп могат да бъдат свързани чрез два различни порта на суич или
            дори чрез отделни суичове. Докато мигриралият от един към друг BSS клиент не
            изпрати фрейм, която да обнови кешовете на L2 устройствата в мрежата, трафикът,
            адресиран до него, ще продължи да бъде изпращан до предходната му точка за
            достъп.

            В hostapd съществува частична имплементация на невлязлата в сила поправка IEEE
            802.11f, която се грижи при свързване на нова станция да изпрати от нейно име
            LLC фрейм до целия Ethernet сегмент[7].

            С наскоро приет пач, IAPP имплементацията в hostapd вече работи и при двубандови
            точки за достъп[10][11].

            3.2. Ускоряване на свързването с новия BSS

            IEEE 802.11r дефинира два подхода за ускоряване на свързването с BSS-а, към
            който даден клиент преминава. Това е нужно, защото началното ръкостискане при
            WPA и ОСОБЕНО при WPA Enterprise е доста времеемко.

            Двата подхода са preauthentication по въздуха и preauthentication по системата
            за дистрибуция. hostapd поддържа поне ft-over-ds[8] за WPA И за WPA Enterprise.

            4. Бъдещи имплементации

            На базата на проучването ми на имплементацията на 802.11r, k и v, може
            да се укаже, че от нова имплементация на client steering няма нужда, но това ще
            стане ясно по всяка вероятност чак след OF, ако изобщо.

            Междувременно, Марияне, ако имаш голяма нужда от дадената функционалност, бих ти
            препоръчал да надградиш форка на Google с дистрибутирано изграждане на
            съответните списъци от станции и да добавиш допълнителна информация за
            качеството на връзката с тях.

            [1] Секция „Neighbor table“ на
                http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf <http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf>
            [2] https://www.youtube.com/watch?v=yZcHbD84j5Y <https://www.youtube.com/watch?v=yZcHbD84j5Y>
            [3] https://gfiber.googlesource.com/vendor/opensource/hostap/+/724e9301587faf2d6b13aaa1b09c9914355cc202 <https://gfiber.googlesource.com/vendor/opensource/hostap/+/724e9301587faf2d6b13aaa1b09c9914355cc202>
            [4] Секция „Fast Session Transfer (FST) support“ на
                http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf <http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf>
            [5] http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.html
            <http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.html>
            [6] Секция „Radio measurements / location“ на
                http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf <http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf>
            [7] Секция „IEEE 802.11f“ на
                http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf <http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf>
            [8] Секция „IEEE 802.11r“ на
                http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf <http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf>
            [9] https://petko.me/openfest/wifi/2014/11/09/openfest-wifi.html <https://petko.me/openfest/wifi/2014/11/09/openfest-wifi.html>
            [10] https://patchwork.ozlabs.org/patch/656818/ <https://patchwork.ozlabs.org/patch/656818/>
            [11] https://github.com/lede-project/source/pull/242 <https://github.com/lede-project/source/pull/242>


    _______________________________________________
    Lug-bg mailing list
    Lug-bg@xxxxxxxxxxxxxxxxxx <mailto:Lug-bg@xxxxxxxxxxxxxxxxxx>
    http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg>




_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg


_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.

Hosted by SiteGround Inc