Здравейте, Някой да е стинал до решение? Или задълбочени тестове за по-голяма насока?
Данчо. 2016-08-24 12:37 GMT+03:00 Svilen Ivanov <svilen.iva...@gmail.com>: > Съжалявам за спама, исках да отговоря директно на Петко > > > On Wednesday, 24 August 2016, Svilen Ivanov <svilen.iva...@gmail.com> > wrote: > >> 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=h >>> ostapd/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=h >>> ostapd/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=h >>> ostapd/hostapd.conf >>> [7] Секция „IEEE 802.11f“ на >>> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=h >>> ostapd/hostapd.conf >>> [8] Секция „IEEE 802.11r“ на >>> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=h >>> ostapd/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 > >
_______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
