Re: OpenWrt auto migration
Marian Marinov <[email protected]> Thu, 10 Nov 2016 21:21:26 +0200
| Newsgroups | gmane.linux.region.bulgaria |
|---|---|
| Message-ID | <[email protected]> |
Петко, разкажи, какво направи за openfest и до колко това е помогнало за по-добрият wifi. Мариян On 11/10/2016 08:23 PM, Yordan Georgiev wrote: > Здравейте, > > Някой да е стинал до решение? Или задълбочени тестове за по-голяма насока? > > Данчо. > > 2016-08-24 12:37 GMT+03:00 Svilen Ivanov <[email protected] <mailto:[email protected]>>: > > Съжалявам за спама, исках да отговоря директно на Петко > > > On Wednesday, 24 August 2016, Svilen Ivanov <[email protected] <mailto:[email protected]>> wrote: > > Respec!!! > > On Tuesday, 23 August 2016, Petko Bordjukov <[email protected]> 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 > [email protected] <mailto:[email protected]> > http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg> > > > > > _______________________________________________ > Lug-bg mailing list > [email protected] > http://linux-bulgaria.org/mailman/listinfo/lug-bg > _______________________________________________ Lug-bg mailing list [email protected] http://linux-bulgaria.org/mailman/listinfo/lug-bg