Linux-Bulgaria.ORG

Здравейте,

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

Данчо.

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

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

On Wednesday, 24 August 2016, Svilen Ivanov <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
[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@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] OpenWrt auto migration