Съжалявам за спама, исках да отговоря директно на Петко
On Wednesday, 24 August 2016, Svilen Ivanov <svilen.iva...@gmail.com> wrote: > Respec!!! > > On Tuesday, 23 August 2016, Petko Bordjukov <bordju...@gmail.com > <javascript:_e(%7B%7D,'cvml','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/+/7 >> 24e9301587faf2d6b13aaa1b09c9914355cc202 >> [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
