Изначально я хотел написать не перегруженную техническими терминами ретроспективную заметку о том, в каких исторических условиях в начале 2000-х стали возможными выход на рынок и обретение популярности нового тогда класса устройств — домашние роутеры. Об уходе на покой диалапа, DSLа и всех прочих ужасов тёмных веков Интернета. И, разумеется, затронуть тему знаменитого Linksys WRT54G в контексте того, как он и его «потомки» открыли для меня широчайшие возможности экосистемы WRT.

Набросав первый черновик, я внезапно обнаружил, что таких обзоров на Хабре написано уже несколько штук — они находятся в поиске по ключевому слову «WRT54G». Так что тему пришлось сменить и поэтому я попробую рассказать, как я в некотором смысле «перерос» WRT, какие технические трудности возникли на этом пути и как их удалось решить.

Чем вообще привлекателен формат домашнего роутера для нетребовательных пользователей? Во-первых, дешевизной и доступностью. Они значительно дешевле аналогичных решений промышленного класса. Во-вторых, низким энергопотреблением и отсутствием в конструкции движущихся частей, что обеспечивает долговечность устройства. В-третьих, простотой настройки, которая зачастую доходила до абсурда в виде компакт дисков "Easy Setup", включенного по умолчанию WPS и тому подобного. Всё перечисленное гарантировало роутерам огромную популярность в качестве устройств доступа в Интернет для дома или малого офиса. Аппаратные их возможности хотя и не велики по сравнению с «настоящими» роутерами, но для просмотра котиков на работе или для вечерней релаксации всей семьёй вполне хватает.

Дома у меня сменилось несколько моделей роутеров. Последним из них был безотказно проработавший почти семь лет TP-Link WDR4300. На момент выхода это был козырный аппарат — двухдиапазонный (2.4 + 5 ГГц), с гигабитными портами WAN+LAN и двумя USB2, мощным по тем временам процессором Atheros AR9344 на 560 МГц, а главное — 8 МБайт флеш-памяти и 128 МБайт ОЗУ. В заводской прошивке у него не было поддержки нужного мне туннелирования IP6-in-IP4 RFC4213, так что к нему был немедленно подпаян USB-RS232 и влита собранная тут же из BuildRoot прошивка OpenWRT. Многие годы он рулил моей домашней сетью, крутя внутри себя iptables, dhcp, radvd, hostapd, sshd и ещё много других страшных слов.

Приключения начались в момент разглядывания уныло ползущего прогрессбара загрузки в qBittorrent. Нет, провайдер давал честные 100 Мбит/с в обе стороны, но хотелось больше драйва. И тут соседний провайдер гигабит раздаёт по акции за смешные деньги. Сказано — сделано. Пришли монтажники, провели, протестировали, ушли. Цепляю я своего старичка — 200 Мбит/с. Что такое? Цепляю системник — 950. Значит, проблема в роутере.

Да, к сожалению, счастливые обладатели гигабитного канала и роутера с заводской прошивкой, которая легко справляется с этим гигабитом могут обнаружить, что самый часто задаваемый вопрос в сообществах проектов *WRT это «Посоветуйте роутер с *WRT и поддержкой гигабитного канала?». И что правильный ответ на этот вопрос, увы — «Нет таких». Причина этого обычно кроется в нехватке процессорной мощности в low-end устройствах. Не то чтобы NAT в TCP/IP был каким-то особенно вычислительно-интенсивным процессом, но даже простой пересчёт контрольной суммы IP пакета при трансляции на таких скоростях CPU уже не вывозит. Заводские прошивки могут себе позволить проприетарные драйвера к сетевым интерфейсам с поддержкой различных типов разгрузки (offload engine), которая передаёт некоторые функции TCP/IP на контроллер сетевой карты и разгружает CPU, но в Linux, на котором основан OpenWRT, с этим до сих пор всё очень плохо.

Чтобы уплаченные за гигабит деньги не пропадали зря, пришлось извращаться и подключить домашку через два роутера. Первым на входе стоял Cisco RVS4000 (у которого от Cisco только наклейка на корпусе) и занимался он только и исключительно гигабитным NATом на заводской прошивке. За ним стоял гигабитный свич, а за ним уже всё остальное, включая торчащего в DMZ старичка WDR4300, который всё так же рулил сетью. Таким образом заветный гигабит в секунду в обе стороны таки был получен.

Но было одно но. По какой-то неясной причине, подозрительно совпадающей по времени появления с проблемами с электричеством в доме, sit-туннель, терминированием которого занимался и так уже сидящий за NATом WDR4300, внезапно переставал подавать признаки жизни, а через несколько часов так же внезапно оживал. Провайдер клялся и божился, что никакой фильтрации на эту тему (IP протокол 41) у них нет. На конец туннеля на других серверах траффик проходил без проблем, а вот на продакшен сервер, который мне был нужен — фигвам. Бесила невозможность запустить tcpdump на внешнем интерфейсе RVS4000 и посмотреть, чем он там страдает — не только для диагностики проблем с туннелем но даже и просто для того, чтобы посмотреть, как и какой траффик приходит на него из Интернета.

После года таких страданий во время очередного зависания туннеля я решил, что время пришло и пора собрать уже роутер по-взрослому, на x86_64 и с процессором, который закроет вопрос гигабитного NAT в принципе и навсегда. Уже чёрт с ними с вентиляторами, душевный комфорт и доступный инструментарий диагностики стал важнее.

Подходящей основной для такого решения я посчитал материнскую плату ASRock Z370M-ITX/ac. У неё, во-первых, было ДВА гигабитных Ethernet-порта, что для материнских плат формата ITX большая редкость. Во-вторых, у неё был встроенный двухдиапазонный (2.4 + 5 ГГц) Wi-Fi и даже антеннки к нему в комплекте. Влепив на это чудо 8 ГБ памяти и Intel Core i3-9100F, я приступил к сборке Gentoo Linux на нём.

Первые подозрения вызвал тот странный факт, что эти два Ethernet были на разных чипах. Один был Intel I219-V [8086:15b8] и работал на драйвере e1000e, второй был Intel I211 [8086:1539] и работал на драйвере igb. Значимость этого факта я обнаружил во время тестирования скорости канала. Подключив наружный кабель к одному порту, получил скорость загрузки в 500 Мбит, а выгрузки в 1000. Подключив к другому, получил скорость загрузки в 1000, выгрузки в 500. Это какая-то мистика, которая, может быть, даже и не аппаратного характера, и которую мне ещё предстоит решить в будущем. Уж больно круглое соотношение, неспроста это ж-ж-ж-ж.

Следующий сюрприз поджидал меня при попытке настройки точки доступа Wi-Fi на основе имеющегося на борту Intel Dual Band Wireless-AC 3168NGW [Stone Peak] [8086:24fb]. У WDR4300 было честных два радиоинтерфейса, которые были настроены отдельно друг от друга — один на 2.4 ГГц, второй на 5 ГГц и настройка их была тривиальна. У этого же несчастного dualband'а радиоинтерфейс оказался один. Пришлось выкапывать из кучи запчастей внешний USB WiFi Ralink-чего-то там и городить 2.4 ГГц точку на нём. А встроенный наверняка же справится с 5 ГГц точкой?

Ага, щас! iw list бодро отрапортовал ВЕСЬ доступный адаптеру 5 ГГц диапазон как «no IR»

«No IR» это «No Initiate-Radiation», т.е. такой режим при котором радиоустройство может начинать излучение на частоте, только если на ней уже кто-то из его потенциальных визави что-то недавно излучал. Самостоятельно бросаться beacon'ами, как положено каждой уважающей себя точке доступа Wi-Fi — нельзя. Проще говоря, при формальной поддержке режима AP работать в нём на этих частотах никак не получится.

Пляски с regulatory db не помогли. Как оказалось,

Yeah, Intel's documentation very clearly and explicitly states that their consumer cards don't do 5 GHz AP mode.

Here Intel's Luca Coelho explains why: "We don't support AP mode in the 5GHz band, because we don't have a way to detect radar transmissions in order to evacuate the channels..."

Вот сразу хочется этого умника спросить, а как в Atheros научились радар детектировать? У них с точками доступа на consumer cards 5 ГГц нет проблем почему-то.

Значит, оставим Intel в покое и попробуем завести 5 ГГц точку тоже на внешнем USB адаптере? Да, но и это оказалось не простой задачей. Во-первых, мне не удалось найти в продаже (включая вторичный рынок) двухдиапазонные свистки на каком-либо другом чипсете, кроме Realtek RTL8811CU. Поддержки которого нет в актуальной для Gentoo стабильной версии ядра Linux. К счастью, эта проблема неожиданно легко решается.

На этом аппаратные трудности закончились (надеюсь) и пошли трудности программные.

По-хорошему, то есть привычно и так, как это было сделано на WDR4300 и OpenWRT, нужно создать bridge-интерфейс, включив в него LAN и оба интерфейса Wi-Fi, чтобы устройства имели лёгкое унифицированное управление и конфигурацию. А можно ли «сбриджевать» интерфейсы Ethernet и Wi-Fi? Вообще-то нельзя, но если очень хочется, то можно.

Смысл того объяснения по ссылке я не очень понял, но там что-то про разное количество MAC-адресов в заголовках пакетов. Так что если ввести волшебное заклинание

iw dev wifi1 set 4addr on

то интерфейс добавляется в бридж без вопросов, потенциально теряя совместимость с чем-то там (но у меня не потерял почему-то). Ну, во всяком случае, тот интерфейс, где потом поднимается точка на 2.4 ГГц. И встроенный интеловский не возмущается, хотя он и не нужен. А вот внешний на RTL8811CU отказывается. Мол, «Operation not permitted».

На этом месте, угнетённый необходимостью искать в продаже USB Wi-Fi свисток, одновременно умеющий и в 4addr и в Master Mode и с не забитым NO-IRами 5 ГГц каналами, я уже был готов психануть и вернуть WDR4300 по старой схеме, оставив ему только заботу о беспроводном доступе. Но тут на глаза попался странный совет, мол, а ты всё равно запусти hostapd, даже если оно not permitted. Только укажи ему бридж в конфигурации. Указал, запустил. Запустилось. Капризный интерфейс добавился в бридж.

# brctl show
bridge name     bridge id               STP enabled     interfaces
brnorka         8000.5228f4730f07       no              eth0
                                                        wifi1
                                                        wifi2

Бывает же такое.

На этом приключения пока что закончились. Надеюсь, материал этот будет полезен тем, кто планирует собирать что-то похожее.