Respec!!! On Tuesday, 23 August 2016, Petko Bordjukov <bordju...@gmail.com> 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 > [2] https://www.youtube.com/watch?v=yZcHbD84j5Y > [3] 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 > [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 > [6] Секция „Radio measurements / location“ на > 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 > [8] Секция „IEEE 802.11r“ на > 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 > [10] https://patchwork.ozlabs.org/patch/656818/ > [11] https://github.com/lede-project/source/pull/242
_______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
