Безжичната мрежа на OpenFest 2014
by Vasil Kolev(това е писано от Петко Борджуков и публикувано в сайта на OpenFest 2014, препубликувам тук с неговото разрешение)
Основният подход при изграждането на безжичната мрежа в Интерпред се въртеше около два основни принципа – много хардуер и липса на сложна конфигурация.
Хардуерът
Тази година Крокодила си беше поставил за цел да имаме поне 10 устройства, които да пръснем из сградата. В крайна сметка имахме 11:
ap00 - alix2d2 с dnma92 и cm9 MiniPCI Wi-Fi карти (София – дясно)
ap01 - alix2d2 с dnma92 и cm9 MiniPCI Wi-Fi карти (G3)
ap02 - alix3d2 с dnma92 MiniPCI Wi-Fi карта (София – ляво)
ap03 - alix3d2 с dnma92 MiniPCI Wi-Fi карта (G1)
ap04 - Cisco WAP561 (Пловдив)
ap05 - Cisco WAP561 (Бургас)
ap06 - alix3d2 с TP-Link MiniPCI Wi-Fi карта с чипсет AR9280 (G1)
ap07 - alix3d2 с cm9 MiniPCI Wi-Fi карта (резерва)
ap08 - alix3d2 с cm9 MiniPCI Wi-Fi карта (резерва)
ap09 - TP-Link WDR4300 (лоби)
ap10 - TP-Link WDR4300 (Варна)
С изключение на двете устройства Cisco, всички използвани Wi-Fi карти бяха с чипсет Atheros. dnma92 е двубандова и поддържа 2×2 MIMO, cm9 е двубандова, но поддържа само 802.11b/g, двете устройства TP-Link поддържат 3×3 MIMO на
5-гигахерцовата си карта и 2×2 на 2,4-гигахерцовата.
Софтуерът
На всички устройства (с очевидното изключение на двете Cisco) беше инсталирана OpenWRT Barrier Breaker, рекомпилирана с CONFIG_PACKAGE_ATH_DFS=y и CONFIG_ATH_USER_REGD=y, което да позволи използването на канали от 52 до 64.
Допълнително на всички железа беше пуснат SNMP сървър.
Конфигурацията
Имахме три основни разновидности на конфигурацията на точките за достъп – 802.11n в 5GHz и 2,4GHz спектър, 802.11b/g в 2.4GHz спектър и двете Cisco.
Обща част
Всички точки за достъп извършваха .1q тагване на рамките и бяха свързани с останалата част от мрежата през един „trunk“ порт и имаха следната конфигурация на мрежата:
management: eth0.600
wireless (bridge mode): eth0.601, wlan0 и wlan1, ако има такъв
Бриджът, в който са добавени безжичните интерфейси, няма никакъв адрес от трето ниво.
Интервалът за излъчване на beacon рамки беше 250 милисекунди, за да се намали натоварването на каналите (повече за това – в частта за мрежата за бавни устройства). Докато експериментирах с тази настройка, забелязах, че понякога Wi-Fi клиентите не откриваха дадена точка за достъп при сканиране. Този проблем се наблюдаваше, при beacon интервал по-голям от 300ms.
На безжичните карти беше зададена България за regulatory domain и беше активирано излъчването на 802.11d информационен елемент в beacon рамките с надеждата клиенти, които по подразбиране на поддържат канали 12 и 13 да бъдат „заразени“ с правилния regdomain от някоя точка за достъп на видим от тях канал.
Точките за достъп бяха конфигурирани да си говорят по 802.11f, за да се намали времето за миграция на клиент помежду им. Това наложи да оправя поддръжката на .11f в конфигурационните скриптове на OpenWRT, защото в Barrier Breaker по подразбиране IAPP работи само в шифрирани мрежи, и дори в този случай се чупи, заради използване на изведени от употреба команди за установяване на име на физически интерфейс (eth0.600 например) по име на логически интерфейс (wan, lan, и т.н.).
Силата на сигнала на всяка точка за достъп беше далеч под максималната – почти всички радиа бяха конфигурирани да излъчват с между 8 и 10dBm с цел да се „поощряват“ клиентите да преминават между тях. 5-гигахерцовите радиа бяха усилени малко повече отколкото 2.4-гигахерцовите, за да ги предпочитат двубандовите клиенти (не беше особено ефективно, повече – за догодина). Отнесох доволно количество подхвърляния докато се разхождах с лаптопа си в петък, гледайки силата на сигнала и дали машината ми преминава между точки за достъп по очаквания начин. Това беше едно от най-досадните неща за конфигуриране.
Точките за достъп за бавни устройства (със SSID OpenFest Legacy Devices)
Още от преди да започнем да мислим мрежата, от няколко места ни предупреждаваха да „отрежем бавните устройства, защото забавят всички други“. Крокодила настояваше за отделна Wi-Fi мрежа за бавни устройства, за да няма хора без Интернет на Феста.
Реших да изровя малко повече информация по въпроса, преди да се втурна да се доверявам на необосновани подхвърляния. Открих следните две статии: http://www.revolutionwifi.net/2012/12/wi-fi-probing-behavior-and-configured.html и http://www.revolutionwifi.net/2010/10/limit-ssids-data-rates-to-maintain.html, които ми разясниха същността на проблема.
Решението беше да заделя един канал, който да е изцяло за стари устройства и да ги оставя да си работят там, за да им е бавно само на тях. Двете виртуални точки за достъп, които бяха заделени за тях (вж. графика 1), бяха конфигурирани да излъчват на първи канал и да поддържат всички Basic Rates – от 1 до 54.
Точките за достъп за бързи устройства (със SSID OpenFest 2014)
Всички виртуални точки за достъп, които бяхме зачислили за бързи устройства, бяха оставени изрично само с 54Mbps basic rate.
Двете точки за достъп Cisco (със SSID OpenFest)
Изрично бяха с различно SSID, за да бъдат извън „роуминг домейна“ на машините ни с OpenWRT. Конфигурацията им се състоеше в това да им сложа парола, да задам в кой VLAN да бъдат виртуалните им точки за достъп и да им намаля радиата до минимум (или 25%, според уеб интерфейса им).
Разпределение на каналите
Имахме ограничено физическо пространство, в което трябваше да работят заедно 6 точки за достъп в 2,4-гигахерцови спектър и 5 – в 5-гигахерцовия. Разпределението в 5-гигахерцовия спектър беше лесно, защото там имаме достатъчно на брой канали, които са на разстояние повече от 20MHz един от друг, а и затихването на сигнала в този спектър е по-голямо.
Конфигурацията на 2,4-гигахерцовите мрежи обаче не беше толкова лесна за избор – в крайна сметка реших да разделя спектъра на 1-и, 4-и, 7-и, и 13-и канали, за да оставя 13-и канал незашумен.
Физическо разпределение
Наличието на толкова хардуер наложи да се разпредели предварително по зали и в зависимост от това да се измисли как да бъдат разпределени каналите. В крайна сметка (в три часа сутринта на първи ноември) се спрях на следната конфигурация:
Проблеми
Проблемите (за щастие) бяха малко и с ограничен ефект.
В края на първия ден имахме проблем с деасоцииране на клиенти от една или няколко точки за достъп. За съжаление, не успяхме да определим причината – от части заради ограниченото време, в което проблемът продължи, от части от това, че нямахме удобен метод за централизирано следене на безжичната мрежа.
Дебъгването на този проблем изведе наяве и друг – тъй като всичките точки за достъп бяха в един Ethernet сегмент, ARP заявките (както и теоретично всеки друг Ethernet broadcast) се излъчваха в радиоефира от всяка точка за достъп. Това стана особено забележимо в края на първия ден, когато доста от хората си бяха тръгнали. ARP таблицата на рутера се беше поизпразнила, за разлика от NAT таблицата му. Наблюдавахме излъчване на около 20 ARP заявки в секунда, идващи от самия рутер. Това е проблем, който ще трябва да решим за следващата година.
Бележки
Няколко души изразиха силно съмнение в това, че двата TP-Link WDR-4300 ще се справят. Устройствата си работиха абсолютно безпроблемно, без значение, че са на по-малко от половината от цената на Alix устройство с нужната периферия.
Неща, които липсваха
Липсваха ни скриптове, които да извеждат броя закачени клиенти на всяко радио, RSSI за всеки клиент, MAC адреси и т.н. SNMP сървъра, предложен в пакетната система на OpenWRT доста лесно се надгражда, но нямахме време да си ги допишем.
Липсваше ни система за централизирано наблюдение и управление на точките за достъп. Имахме само 7 устройства, които да се конфигурират на ръка, но това не пречеше да е досадно да се настройва конфигурация отделно на всяко желязо. Да не говорим, че търсенето към кое AP е закачен определен клиент беше също доста бавно и неефективно.
Мрежите ни бяха отворени. Мисля, че толкова много хардуер би се справил с конфигурация, подобна на тази на CCC – WPA Enterprise, който приема всяка комбинация на потребителско име и парола.
Липсваше ни метод за подтикване на двубандовите клиенти да се закачат на 5-гигахерцова мрежа. Тук нямаме тривиално решение – или трябва да имплементираме нещо ново в hostapd, или да измислим нещо хитро с blacklist-ване на всички MAC адреси по подразбиране за всяка 2.4GHz мрежа. Идеи са добре дошли.
Не успяхме да си изпрограмираме спектрален анализатор, който да приема данни от HackRF-а на Крокодила и да ни рисува Density Map в (близко до) реално време. Оглеждам https://www.kismetwireless.net/spectools, на които трябва да им се допише поддръжка за HackRF.
Благодарности
Благодарим на Elwix, BIX, Нет Ис Сат и Точо за заетия хардуер.
Петко