татко Крокодил

Снощи (до тая сутрин) бях на концерт на Concrete Sun, Villagers of Ioannina City и Smallmanband, на стандартното място в mixtape.
(добро прекарване на в общи линии първия/втория ми безработен ден)

Влизането се забави с около час (което май е стандартно), но първата група почна почти веднага след като хората влязоха. Concrete sun изобщо не ми бяха интересни, звучаха стандартно и плоско, като … в общи линии новата metallica. Бяха и малко прекалени във викането към публиката, но явно тва им е стила на действие.

Вторите бяха Villagers of Ioannina City и тотално размазаха. Не знам дали мога да ги опиша, но имаха една отнесена китара, доста приличен (и добре чуващ се) бас, един човек на духови инструменти (да гледаш как някой подскача и куфее с кларинет е любопитно), клавир и доста странни ритми. Като цяло, странен и ставащ за танцуване метъл (няколко човека отидохме след като свириха да си вземем CD-то им, аз тъкмо си го въртя).

А smallman си бяха smallman. Свириха си с кеф, изсвириха всякакви интересни неща и завършиха заедно с клавириста на Villagers с едно изпълнение на Angel на Massive attack. Раздвижихме добре куфелния мускул, попяхме/повикахме и като цяло преживяването си струваше висенето до 3 :)

(ужасно вредно е да се чете Пратчет от лесно-пристрастяващи-се-хора, за поредна вечер седя до 3, за да си дочета книгата)

След някакво количество по-тежки книги – всичкия Оруел и последствията от него (Albert Maltz, Евгени Замятин, E. Tangye Lean), после Echopraxia на Peter Watts и т.н. (тук може да се види списъка), реших да си почина с малко Пратчет. Хванах каквото ми беше под ръка (Jingo), после продължих с нещата за стражата, първо по-тежките (“Night Watch”, “Thud!”), след продължих с първите (“Guards! Guards!” и т.н.).

Накрая снощи изчетох “The last continent”, и изведнъж си спомних/открих пак, че той всъщност е адски смешен – смях се бая време на разните шеги (които в оригинал определено са по-добри, май ще си планирам препрочитане на старите неща). Езикът му е страхотен, идеите му също, и малките и дребните шеги се получават много добре. Явно в някакъв момент след серията с магьосниците нещо е станало с него (и не е алцхаймера, щото той дойде доста по-късно) – докато преди идеята на книгата беше важна, но беше важно и да е смешна, в последните му неща важността на идеята избутва хумора доста назад, сяка
ш е нямал желание да се шегува толкова.

Това не пречи на книгите му и не ги прави по-трудни/бавни/тегави/лоши за четене – спомням си как като излезе “Нощна стража” на български като свърших да я чета, открих, че е сутрин (и в съседната стая Велин откри същото) – но ги прави доста различни, може би с по-силен поучителен момент.

Също така, тоя частичен препрочит ми показа, че определено серията за света на Диска трябва да се прочете от повечето хора. За предпочитане – в оригинал (и през деня, че да се намира време за сън).

(това е писано от Петко Борджуков и публикувано в сайта на 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, Нет Ис Сат и Точо за заетия хардуер.

Петко

И ето едно описание на малкия ни streaming setup (използван по турнето и на OpenFest в по-малките зали).

Като за начало, ето картинката, по която ще се движим, в pdf и vsd формат.
На картинката имаме следните означения:
– червените линии са безжична връзка;
– светлосините – стерео по кабел;
– тъмнозелените – mono по кабел;
– тъмносините неща са бележки;
– бележката “OPT” значи нещо, без което можем да минем.

В бележките където има отбелязани жакове значат следното:
– 6.35мм, 3.5мм – моно/стерео, големи и малки жакове;
– RCA, известни при нас като чинчове;
– firewire – IEEE1394, още го ползваме да си връзваме камерата.

Компонентите са следните:
– аудио миксер;
– безжични микрофони, брошка и дръжка (AKG и HED в тая схема);
– слушалки (headphones) за наблюдаване и дебъгване;
– лаптоп за encode-ване и пускане на музика (опционално);
– озвучаване на залата (Room PA or speakers);
– камера
– amphony L1500 за безжично пренасяне на звук
– проектор
– лектор, с лаптоп
– мрежа

Идеята на цялото нещо е следната – в аудио-миксера се събира целият звук – лектор, въпроси, лекторски лаптоп, музика, и се пуска към озвучаването на залата и отделно към камерата. Не се използва атмосферния микрофон на камерата, понеже тя много често не е на място, което може да слуша добре звука (последният такъв опит беше първата VarnaConf, където звукът беше толкова зле, че записите в общи линии не стават).

За stream-ване звукът влиза в камерата от пулта, и през firewire се дърпа от encoding лаптопа. Задължително е да има слушалки на камерата, за да може да се прецени как е звукът, който влиза в нея.
Със звука на камерите има следния проблем – доста от тях имат AGC (automatic gain control) и когато е тихо, усилват до невероятна сила фоновия шум (тих брум от миксера или просто шума в залата). За това е важно на всичките камери да се намери къде е и да се спре, и да се настрои нивото на входа.

Setup-ът на лаптопа е доста забавен, и изглежда по следния начин:
Избира се някаква директория, в която ще се записва видеото, и в нея се създава named pipe, който да се казва av.m2t (разширението е донякъде важно). След това в два терминала (note to self – да го направя на един скрипт) се пускат следните неща:

dvgrab –format raw –size 0 – | ttee av.m2t log.`date +%s`.m2t
(ttee може да се свали от github, като там трябва един fix, ако се ползват 32битови машини да се компилира с 64-битов file offset, за да не гърми на 4GB файлове).

avconv -i av.m2t -v:c copy -a:c copy -f mpegts udp://10.99.0.1:2500
(вместо avconv може да се ползва ffmpeg, то реално е същото)

С малко patch-ване може трите да се сложат едно след друго (ако ttee плюе на stdout), но тогава трябва да му се спре output-а на stderr, че терминала се напълва с глупости.
avconf/ffmpeg изпраща stream-а до един централен encoder, който да го encode-не и прати до restreamer-а. Правим го, за да decouple-нем записа от encode-ването (щото записващите лаптопи са слабички, а и като спре stream-а да не се чупи записа), описано е в предишния пост.

На някои лекции трябва да се пуска звук от лаптопа на лектора. За целта този звук трябва да се закара от лаптопа на лектора (който е отпред) до пулта (който най-често е най-отзад в залата). По принцип една опция е да се пусне дълъг кабел (който обаче може да направи проблем с брум и като цяло да няма откъде да мине или да няма такъв), за това ползваме най-често едно Amphony L1500, което може да носи звук цифрово през ефира. То си има малки бъгове (понякога някакви неща на 5ghz му шумят, и също така трябва да има активност, иначе спира да предава и трябва да минат 3-4 секунди със звук, преди да започне да предава пак), но като цяло за тази цел върши много добра работа.
Най-крайният вариант (който много много много избягваме) е лекторът да си сложи микрофона на колонките на лаптопа.

На картинката има няколко опционални неща:
– звукът за лектора (не на всички им трябва);
– мрежата за лектора (пак така, някои са оптимисти и ползват wifi);
– слушалките на пулта – по принцип се чува достатъчно добре от озвучаването в залата.

Setup-ът, въпреки голямото описание е доста прост и отнема половин час за сглобяване и 10-15 минути за събиране. Използвахме го в този му вид за повечето конференции тази година, а подобен на него – за последните 3-4 години.

(мислех да oпиша първо как правим записите и stream-а в малките зали на Interpred, но там ще трябва да чертая схеми и ще ги оставя за по-нататък)

За да можем да гледаме събитието локално и по Internet, тази година направихме следния restream setup:

Навън (в delta.bg) имахме сложена една машина, наречена grendel, която имаше 10gbps порт и достатъчно свързаност, че да може да ни бута трафика (още ме е яд, че не минахме 1gbps, догодина може нарочно да пуснем fullhd 1080p stream само за това). На него имаше пуснат nginx с nginx-rtmp модула, който приемаше stream-а и пускаше на потребителите rtmp и HLS. Имахме също страничка, която можеше да показва видеото директно в browser-а и я показвахме в iframe на сайта на OpenFest.

Графика на трафика на restreamer-а.

Същият restreamer с nginx имахме и на router-а в самия Interpred, и там препращахме потребителите, които искаха да гледат локално (и overflow телевизорите/лаптопите). Препращането ставаше чрез split DNS, т.е. за stream.openfest.org връщах локалният ip адрес вместо този на grendel.
Нямам графика на тоя трафик отделно, в общи линии би трябвало да е разликата между външния интерфейс и вътрешния интерфейс на router-а.

На restreamer-ите нямаше ipv6, понеже така и не успях да накарам някой от моите клиенти да работи по v6 за rtmp и мисля, че щеше само да създаде странни проблеми.

В настройките на nginx-а няма нищо, което да го няма в default-ната конфигурация, та ще ги пропусна. Единственият по-куц момент е, че явно модула не е дописан и на повече от един worker нещата се чупят, т.е. реално трябва да се праща по един stream на всеки worker, което не е ясно как може да се направи, или да се допише така, че м/у worker-ите да може да се дели един stream (което значи да му се добави shared memory и да се пише внимателно).

Самите потоци с видео влизаха на eagle, и от там биваха пуснати до двата сървъра. От по-малките зали пращахме директно по UDP raw HDV потоците, а от зала София, поради възможностите на restreamer-а – RTMP.
Причината за UDP-то (което беше една много добра идея на Петко) е, че така се получава decouple-ване на софтуера, който изпраща и записва от този, който приема, т.е. ако умре restreamer-а в който и да е момент, записващата част няма да има проблем, и ако restreamer-а се върне, ще може директно да продължи да чете потока от мрежата.

За encode-ването използвахме ffmpeg, ето как (с някои дребни промени по url-тата):

ffmpeg -re -i 'udp://@10.3.0.1:2600?overrun_nonfatal=1&buffer_size=81921024&fifo_size=178481' \
	-c:v libx264 -s 1280x720 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
	-b:v 2000k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
	-flags +global_header -strict -2 -threads 2 \
	-f tee -map 0:v -map 0:a "[f=flv]rtmp://localhost/of/g1|[f=flv]rtmp://1.2.3.4/of/g1" \
	-c:v libx264 -s 854x480 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
	-b:v 500k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
	-flags +global_header -strict -2 -threads 2 \
	-f tee -map 0:v -map 0:a "[f=flv]rtmp://1.2.3.4/of/g1-low|[f=flv]rtmp://localhost/of/g1-low"

Тук има няколко интересни неща:
– Вдигнали сме буферите на UDP-то за приемане на пакети (и имаме същото нещо от другата страна, за изпращане). В първоначалните тестове (по време на setup-а YAPC::EU 2014) открихме, че UDP е наистина unreliable на default-ните буфери (около 256к) за толкова много трафик и губи достатъчно пакети, че картината да се намазва почти постоянно. Съответно след като с тестове се видя, че при TCP проблемът го няма, лесно се стигна до правилния извод и от тогава тия неща ни работят като слънце.
(интересното е, че на VarnaConf правихме тоя setup без да вдигаме буферите и работеше, и едното съмнение беше, че щото е бил прав кабела м/у двете машини и без никакви switch-ове нещата са били ок. По-вероятно ми се вижда просто някой буфер да е бил по default по-голям на тогавашния ни encoder (един лаптоп на Петко), но няма как да го проверим).
(тази опция изисква и да се пипнат едни sysctl-та по kernel-а, имайте го предвид)

– ffmpeg-а може да създава няколко потока от един вход, и да ги пуска на няколко различни места. Така от един поток можехме да пуснем low и high quality потоци и към двата restreamer-а, без да се налага да се слага нещо по пътя, което да копира пакети или потоци. Наложи се да компилирам една последна версия, че да работи добре, но не беше особен проблем.

– “-g 60” е keyframe интервала, което в общи линии определя колко бързо ще се покаже нещо при потребителя, след като събере някакви данни.

– “-flags +global_header” се налагаше, за да може да бълва rtmp като цяло през тия разчеквания. Не помня как го намерих :)

Като цяло, всичкото това ми отне около два-три часа четене.

За зала София се наложи да направим малка добавка – понеже ffmpeg-а не можеше да слуша на rtmp (т.е. за половин час с Guru не можахме да го накараме), засилихме потока от залата директно в локалния restreamer, и с ffmpeg си го взимах от там и го пращах нататък. Така вкарвахме още 20-тина секунди латентност в излъчването, но пък си решихме доста приятно проблема.

Като цяло този setup не направи никакви проблеми и си работи двата дни като слънце, eдинствено в overflow залите в началото пускахме големия stream от зала София (1080p на 5mbps) и това създаваше малко проблеми на декодерите.

(благодаря на Яна за корекциите по текста)

И ето го описанието на мрежата на openfest. Като цяло изглежда като проект за някой студентски курс по мрежи, няма нещо особено сложно или странно в него, описвам го основно за любопитните хора. Аз ще разкажа за жичната мрежа и топологията, Петко за wireless-а (като намери време и му писне да му мрънкам).

Като за начало, ето генералната схема, в pdf и vsd. Правих схемата на visio, понеже съм му свикнал и още не мога да му намеря еквивалент (а се оказва, че libreoffice вече го отваря).

Топологията беше следната: в “ядрото” (никаква идея защо се казва така) на втория етаж в Interpred влизат кабели до всички нужни зали. Там по принцип има switch на mtel/spnet/каквото-е-там, в който влиза връзката навън и самите зали.
Ние си сложихме там сървъра и един гигабитов switch (core-sw, cisco 3750). В него преместихме кабелите до всички нужни зали, а сървъра (който ни играеше и router) свързахме към техния switch за uplink, и към нашия switch по два порта за streaming vlan-а и за клиентите. В залите, където имахме wi-fi access point-и слагахме managed switch, така че да можем да си занесем дотам двата нужни vlan-а (management и този за потребителите), където имахме камери – също.

Имахме следните vlan-и в мрежата:
600 – management (за нашите си устройства), 10.0.0.0/16
601 – wifi, 10.1.0.0/16 и 2a01:288:4000:32::/64
602 – wired (потребителски портове по switch-овете), 10.2.0.0/16 и 2a01:288:4000:33::/64
603 – streaming (наша техника, пускаща суровите потоци с видео), 10.3.0.0/16
604 – TV (overflow-ове – телевизори и т.н.), 10.4.0.0/16

Толкова голяма мрежова маска за ipv4 при rfc1918 адреси е ок, понеже фоновия трафик от сканирания от internet-а го няма, че да бълваме broadcast трафик постоянно. Имаше проблем с друго, който ще опиша по-долу.
Имахме ipv6 само за потребителските мрежи, по мои наблюдения доста от нашата техника има проблем да си говори с тоя протокол все още, а мотото на setup-а беше “минимални рискове”.
Използвахме нормално per-vlan STP, като беше спряно за VLAN-а на wifi-то, а всички портове бяха в portfast (или какъвто-е-там-еквивалента-извън-cisco) режим. Радвам се, че не ни се наложи да борим цикли или каквото и да е, свързано с него…

Адреси се раздаваха по DHCP за ipv4 и по RA за ipv6.

За да намалим натоварването на външната връзка, със split dns заявките за ip адреса на stream.openfest.org им се отговаряше с адреса на локалния сървър, където имаше същите потоци.

Самия restreaming setup изглеждаше по следния начин:

Трите камери/streamer-и изпращаха до сървъра потоци на голям bitrate/разделителна способност – двете по-малки камери директно HDV потока по UDP, 1080p на 25mbps, setup-а от зала София – 1080p на 5mbps, H.264. На сървъра се reencode-ваха до два формата и се пращаха до големия restreamer (който имаше 10gbps порт) и до локалния сървър, от който също можеха да се гледат. За да няма смесване на този трафик с каквото и да е, всичката A/V техника си имаше отделен VLAN, който беше отфилтриран, така че да не може да влиза в него чужд трафик.

Понеже нямах много вяра и на overflow техниката (и е тривиално да се DoS-не raspberry pi) всичките телевизори бяха в собствен VLAN. На практика, имаше firewall който казваше, че трафик от потребителските мрежи може да излиза само от eth0, не можеше да ходи по нашите vlan-и (600,603,604).

Няколко думи за мрежовата ни техника:
core-sw и sof-pocket бяха две гигабитови cisco-та от netissat (любими switch-ове са ми това, работят идеално, ако се ползват правилно);
quanta беше домашният switch на Мариян, 48-портов гигабитов manageable;
reception-sw беше linksys SWR224G4, който заедно с един SRW2016 (двата от Благовест) ми изпили нервите – не му работеше web контрола, менюто, дето се виждаше по telnet не можеше да настройва VLAN-и, и накрая се оказа, че ако човек се логне, натисне ctrl-z и пусне lcli, там се появява едно доста използваемо cisco-подобно cli, от което всичко става лесно (думи не могат да опишат колко съм благодарен на тоя човек);
Няколко switch-а по залите бяха TP-Link SG-3109 (дойдоха от Unex през StorPool), и направо ми спасиха живота – малки 8-портови manageable, със сериен порт, със същото cli като lcli-то на linksys-а, направо песен за подкарване (чак ми се иска ако намеря такива на нормална цена, да купя 5-6, ще са незаменими за някои събития);
още едно 3750 (от Леков), което отиде за една от залите, понеже дойде в последния момент;
един DLink (от Благо), който замести linksys SRW2016 (пак от Благо), като unmanaged switch за стаята на екипа.

Като цяло крайни потребители се закачаха само в стаите за workshop-и и в team стаята, както и лектора в зала G1 (а трябваше и в другите, ще знаем за догодина).

Следват малко картинки, след което ще разкажа как протече работата на мрежата и какво трябва да направим догодина:

grendel (restreamer-а ни, който ни дадоха Delta.bg):
eth9 – сумарен трафик на порта, през който се stream-ваше за света;

router (eagle):
CPU;
eth0, uplink навън;
connection tracking – статистика по типове връзки;
Power – колко мощност е дърпало захранването на сървъра (не е много смислено, но е забавно);

И от два switch-а, понеже за другите не ми остана време да пусна cacti:
core-sw:
Gi1/0/1, вътрешен порт за потребителския трафик;
Gi1/0/2, streaming VLAN;
Gi1/0/3, зала Пловдив;
Gi1/0/4, зала София (джоб);
Gi1/0/6, зала Бургас;
Gi1/0/7, зала G1;
Gi1/0/8, зала G2;
Gi1/0/9, зала G3;
Gi1/0/10, зала Варна;

sof-pocket-sw:
Gi0/2, рецепция на зала София;
Gi0/3, зала София, десен access point (OFAP02);
Gi0/4, зала София, ляв access point (OFAP00);

Уникални MAC адреси:
1 ноември – 557;
2 ноември – 553;
Общо за двата дни – 769;

MAC адреси по производител, първите 10 (благодарение на Точо, който го изсмята):
Apple 121
Samsung 108
Intel 93
LG 75
HTC 49
Murata 38
Sony 38
Hon Hai 32
Motorola 27
Nokia 24

Вдигането на мрежата мина нормално, само с няколко грешки (основно мои, липсващи vlan-и по switch-ове и някакви промени в последния момент). Кабелите бяха пуснати сравнително лесно, като за това помогна, че не ни беше за пръв път (Явор беше опъвал част от тях по същите места в предишните поне две години), а за останалите имахме достатъчно помощници и клещи. Само един switch беше конфигуриран там на място, тоя за зала Бургас, понеже тогава ни го дадоха (Пешо седя в един ъгъл с кратък списък изисквания от мен и го човърка). Въпреки някои забавяния, мисля, че самата мрежа беше съвсем по график и беше пусната най-лесно, въпреки относително многото хамалогия. Единствените неща, което настроих в петък вечерта в заведението, в което ядохме, бяха IPv6 (понеже не беше толкова приоритетно) и да добавя останалите устройства в icinga-та (която така и не гледахме).

Имахме няколко проблема по време на събитието:

Имаше доста broadcast трафик от arp пакети, за клиенти, които са били асоциирани, после са се разкачили и изчезнали от arp cache, но отвън още се опитват да им пратят нещо. Решението, което сглобих, беше да вадя списък на всички изтекли dhcp lease-ове (чрез някакъв perl скрипт, който намерих в github), и за всички тях чрез conntrack tool-а да трия всичкия им съществуващ state. Не съм сигурен доколко помогна, вероятно тоя broadcast не е бил толкова много така или иначе.

Имаше няколко случая на arp spoof, до които не се добрахме (срам);

В един момент решихме да вдигнем worker-ите на nginx-а на restreamer-а и се оказа, че просто rtmp модула не се оправя с повече от един worker. Това е нещо, което трябва да debug-на за в бъдеще.

И най-идиотския проблем – спираше ни ipv6. По някаква причина от време на време просто сървъра и спираше да отговаря на ipv6 пакети, и да ги route-ва, като все още нямам обяснение защо и не е проблем, който съм виждал където и да е другаде, но със сигурност поне 80% от оплакванията, че не работи wireless-а идваха от android телефони, които просто се опитваха да минават по v6. В списъка ми е да го проверя от какво може да е било, обмислям да изтормозя някой от съществуващите ми v6 router-и и да видя дали мога да го репродуцирам.

За следващия път съм си отбелязал следните неща:

Работещ ipv6 :) (Петко предлага да сме само по v6, но това не звучи като добра идея);
Да отделим хора за NOC, които да следят мрежата и да хващат проблеми (arp spoof-ове и т.н.);
По-подробен monitoring (който да го гледа NOC-а);
Никакви switch-ове и подобни, които отнемат над половин час, за да се подкарат;

(чувствам се адски изморен, добре, че пих два големи lagavulin-а да се освестя, и след тоя post отивам да спя)
(също така, планирам подробен post за как сме направили мрежата и ще изтормозя Петко да напише нещо за как направихме wifi-то, което имаше учудващо малко проблеми/оплаквания)

Искам да напиша една голяма благодарност до доброволците на OpenFest 2014. Екипът си го знае, ние в това сме били бая години и сме тренирани, но тук си говорим за хора, които нямаха идея в какво нещо се забъркват, издържаха два дни юркане, тичане, викане (основно от моя страна) и всякакви странни проблеми, които се появяваха. Routing-а на хората към overflow залите всъщност се получи идеално, в доста случаи и без да се налага някой да тормози – просто екипът доброволци уговаряше и насочваше потока както трябва (нещо, което досега не бяхме правили, нямахме добър опит и тренинг и импровизирахме през половината време).
(сещам се за определението на братя Стругацки, че добрата книга е за обикновеният човек, набутан в необикновени ситуации…)

Утре ще допълня списъка, ето една начална версия:

== Оператори за зала София ==
* Юлия
* Пешо
* Павлина
* Димитър

== Overflow ==
* Росен
* Димитър

== 2ри етаж ==
* Neter

== Мрежов екип ==
* Явор
* Точо

== g1 ===
* Иван
* Благовест

== Varna ===
* Марио
* Владо младши
* Олег

== представяния
* Стефан Кънев

== Unconference хора
* Иван Димитров
* Митьо
* Тони Стойчев
* Божо
* Емануил

== misc
* vloo
* Мюмюн
* Исмаил
* (чичо) Данчо
* Захари
* vloo
* Нейчо
* Доби
* Вальо

== рецепция
* Камелия
* Сияна
* Елеонора

И основен екип (който искрено се надявам да е пиян вече, че имат нужда):
Яна
Мариян
Петко
някакъв зелен идиот
Христина
Стефан Леков
Ирина
Стефан Вартоломеев
Християн (Guru)
Горица