LINUX.ORG.RU

Посоветуйте мощный роутер (с радиочастью или самой дешёвой, или самой топовой)

 , turris-omnia, ,


4

4

Приветствую.

Никогда не думал, что мне будет сложно выбрать роутер... В любом случае, here it goes. Мне нужен мощный роутер, способный NAT'ить 200 Mbps и пропускать через IPsec/WireGuard хотя бы 100 Mbps, и при этом работающий под управлением OpenWRT/LEDE или любого другого полноценного современного GNU/Linux (необязательно «из коробки», но вышеописанные требования должны достигаться на OpenWRT/LEDE, а не только на прошивке от вендора).

К радиочасти (Wi-Fi) требований особых нет: чем дешевле, тем лучше. Она нужна только в качестве временного решения до того, как я куплю UniFi AC HD. Или же, как вариант, она должна быть не хуже UniFi AC Pro (т. е. 802.11ac Wave2 3x3:3), чтобы мне не пришлось покупать AP как таковую (хотя бы до тех пор, пока у меня нет клиентов лучше 2x2:2).

Мне пока что приходит в голову только Turris Omnia + <рандомный Wi-Fi чип из ящика с барахлом> или QCA9982. Кстати, никто не знает, с какими чипами поставляется эта самая Omnia?

Решение: Xiaomi Router 3G.

★★★★★

Последнее исправление: intelfx (всего исправлений: 4)

Ответ на: комментарий от NiTr0

в домашнем роутере оно сильно надо?

ну например зафлашить conntrack по определенному предикату (комбинации src + dst ip), а не целиком. Как это делать, если не через ctnetlink?

что из юзерспеса на типовом домашнем роутере требует более свежей гнуси?
аналогично - для чего это домашней коробочке с натом и парой демонов?

Элементарно - accel-ppp.

какие драйвера нужны домашнему роутеру и зачем? ну разве что 3g/4g модем туда подоткнуть бывает надо, а они как правило cdc...

Да, как минимум модемы (особенно всякие qmi и подобные, cdc это тупо и просто), или тот же самый вендорский mt7615 для wifi (который изначально пишется под 3.10+).

anonymous
()
Ответ на: комментарий от intelfx

Это юзерам openwrt пах*й, что при апгрейде роутер станет тупить в два раза сильнее - им никто гарантий не давал и можно ставить раком как хочется, а попробуй объяснить это обычным юзерам или того более - покупателям, которые заплатили за определенный уровень сетевой производительности.

anonymous
()
Ответ на: комментарий от anonymous

«Покупатели, которые заплатили за определённый уровень сетевой производительности» пусть покупают готовые решения с заранее озвученной функциональностью и не лезут под капот. Здесь разговор не про них. Лично я не хочу использовать васяносборочку на протухшем ядре.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Работаю с Padavan ежедневно, и могу сказать, что специалистов такого уровня по ядру и железу у нас в России по пальцам пересчитать.
Лучший показатель качества его работы - что сторонние люди говорят о созданной им системе как о мегастабильной.
Но ты, щщщенок, продолжай тявкать, продолжай.

anonymous
()
Ответ на: комментарий от NoobeR

List_of_Padavan_firmware_supported_devices

Я, кажется, уже выразил своё мнение по поводу «Padavan firmware» :)

Там есть варианты на 128/128

Они либо на MT7615, либо на MT7610 (1x1:1).

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

а на практике что это даст? по сравнению с 2-кратной просадкой производительности в роутинге?

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

Элементарно - accel-ppp.

и часто вы дома поднимаете туннельный сервер с радиус авторизацией?

или тот же самый вендорский mt7615 для wifi (который изначально пишется под 3.10+).

шутка в том, что вендор уже предоставляет дрова под свой сдк со старым ядром :) и пилить туда более другую вайфайку как-то смысла мало.

NiTr0 ★★★★★
()
Ответ на: комментарий от intelfx

У меня нет гигабитных каналов. У меня есть 200 Мбит/с, и на этих скоростях всё прекрасно работает без hwnat. Так что УМВР, да.

7621? который 2 ядра с многопотоком под 1ГГц каждое? т.е. топовая SoC?

только вот гигабит не прожует :)

Я не читал ни один из них. Не могу ничего дельного сказать.

ну так откройте сдк и опенвртшный костыль и посмотрите что ли.

Вендорский код не всегда лучше, просто потому что он вендорский (зачастую как раз наоборот).

кривопись сообщества, которую из-за кривизны рук ее писавших хрен знает сколько раз заворачивали взад при попытке пропихнуть в mainline - лучше?

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

Под 2.6.20 не поставляет :)
И использовать вендорное ядро - это должны быть крайне веские причины на это.

anonymous
()
Ответ на: комментарий от NiTr0

Раэз от mtk - это пи*ец и кошмар для чтения, очень плохой совет имхо.
Как драйвер он может пойдет, но лезть в него стоит разве что уж очень приспичит.
Там столько всего присрано, и до сих пор дефайны под 3352 есть - его почти невозможно сопровождать (хотя китайцы умудряются как-то это делать).
Не защищаю поделку openwrt, но мы и сами переписали этот кусок говна с нуля, смотря на исходники оригинала, даташиты и прочие места. Потому что сопровождабельно жить с этим калом невозможно.

anonymous
()
Ответ на: комментарий от NiTr0

Да обычный функционал pptp-vpn-сервера на роутере реализовать - чем? Неужели допотопный poptop использовать?
Радиус, ipv6 и прочий шлак там отлично отрезается, и остается очень маленький но вменяемый сервер.

anonymous
()
Ответ на: комментарий от NiTr0

Там еще сложность в том, что многие не понимают (даже из здесь читающих), что у роутера сетевой карты как таковой нет.
Там сразу комбайн из pdma/qdma (это как раз то, что подразумевается под классической сетевой картой), ppe (это проприетарный ip hwnat), pse (программный свитч между этими кусками и реальными портами phy) и phy.
Китайский раэз совмещает в себе управление всем этим говном сразу, он даже ppe частично настраивает (форвардинг в него и обратно).
А вот если в vanilla такое пытаться пропихивать без разбиения на абстракции - конечно же получишь пестоф, и заворачивать будут регулярно. Сначала надо написать максимально обобщенный фреймворк для связывания всех этих кусков в общую кучу (чтобы и атерос/qc, и броадком, и прочая муть ложилась в эту концепутальную модель), и потом уже драйверы для каждого компонента.
Собственно мы это могли наблюдать на примере развития подсистемы mac80211 в ядре на протяжении последних 12-15 лет. До этого wifi-драйверы лепил кто во что горазд. Видимо ethernet-комбайнам это еще только предстоит пройти.

anonymous
()
Ответ на: комментарий от anonymous

Тебе настолько нечего сказать, что ты в первой же реплике переходишь на оскорбления? Ты жалок. Лучше залогинься, а то у меня даже нет возможности узнать, в каком подвале вы там с ним «работаете».

intelfx ★★★★★
() автор топика
Ответ на: комментарий от NiTr0

ну так откройте сдк и опенвртшный костыль и посмотрите что ли.

Мне некогда. Повторяю вопрос — у тебя есть что по делу сказать? Анонимус вот рядом хоть хамит направо и налево, но хотя бы аргументирует.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от anonymous

как по мне - портировать все с вендорного ядра на более свежие должны быть очень веские причины.

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

да можно и поптоп ядреный (который accel-pptp). работает же.

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

Зачем до сих пор таскать с собой этот мусор, если никто в здравом уме на этом ничего уже не делает и чипы уже больше пяти лет не выпускаются?

anonymous
()
Ответ на: комментарий от anonymous

И буду продолжать, поскольку товарищ скрывается за никнеймом и у меня нет никаких способов проверить его опытность и уважаемость.

А проект, в котором один какой-то человек делает «ремиксы» проприетарного софта и вендорских дропов, игнорируя сообщество, по определению называется васяносборочкой — здесь нет никакого хамства.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от NiTr0

включите HWNAT - и торрент будет натиться с загрузкой проца в пару %. на гигабите, да.

И получишь bufferbloat и пинги под нагрузкой по несколько секунд)
На mir3g очень хорошо взлетает OpenWRT + cake aqm. Да и над mt76 вафлей сейчас make-wifi-fast колдуют.

Загрузка проца - фигня, это не десктоп, чтоб её экономить. Кстати, а -rt ядро в openwrt не взлетело по какой причине?

devl547 ★★★★★
()
Последнее исправление: devl547 (всего исправлений: 2)
Ответ на: комментарий от intelfx

Ну ок, предположим что не Padavan, а Juan Zea. Лучше стало? Понятнее? Авторитетность прям на раз повысилась?
Где он игнорирует сообщество? А это тогда что: https://bitbucket.org/padavan/rt-n56u/pull-requests/ ?
Более того, там даже открыты все исходники и все изменения, в том числе и в вендорских «дропах». Анализируй да собирай - нехочу.

anonymous
()
Ответ на: комментарий от devl547

Нет там никакого bufferbloat по причине отсутствия заметного буфера как такового. Железо аппаратно работает с пакетами, они даже pdma не достигают - только pse, а у него буфер чисто аппаратный и на несколько десятков пакетов всего в сумме. А pdma и более верхние слои полностью свободны, и потому пинг самый минимальный.

Загрузка проца - фигня, это не десктоп, чтоб её экономить.

Сразу видно человека, который никогда не касался эмбеддед даже метровой палочкой.

anonymous
()
Ответ на: комментарий от anonymous

Фиг там, у меня mi router 3 и 3G есть - стоит забить канал с другого компьютера, как пинги взлетают в небеса.
При использовании aqm такого уже нет.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

И получишь bufferbloat и пинги под нагрузкой по несколько секунд)

как анонимус выше написал - лютый бред.

по-вашему, л2 свич, аппаратно перекладывающий пакеты из порта в порт, приведет к bufferbloat'у и пингам по несколько секунд? нет?

а может л3 свич приведет к bufferbloat'у? что, тоже нет?

тогда почему hwnat приведет к bufferbloat'у? только потому, что он меняет ip/mac в пролетающем пакете на лету? :)

Загрузка проца - фигня, это не десктоп, чтоб её экономить

да-да, фигня. особенно когда на каких-то 100-200 мбитах торрентов, с кучкой сессий в коннтраке эдак 2-3-5 тысяч, проц уходит в полочку (вплоть до ребута по вочдогу), с тормозами и дропами пакетов :)

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

Ну ок, предположим что не Padavan, а Juan Zea. Лучше стало? Понятнее? Авторитетность прям на раз повысилась?

Да. Стало лучше. Я могу загуглить «Juan Zea» и понять, что это какой-то ноунейм, к которому нет никакого доверия.

Где он игнорирует сообщество?

Там, где он возится в собственной песочнице, вместо того, чтобы коммитить в OpenWRT.

Более того, там даже открыты все исходники и все изменения, в том числе и в вендорских «дропах».

Это не имеет никакого значения. Имеет значение то, что отсутствует процесс peer review.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от NiTr0

Нет, это отлично, но для них нужно писать отдельный драйвер, пусть и с дублирующимся кодом, а не лепить этого урода, состоящего на 30% из #ifdef/#endif.
На мой взгляд отдельный драйвер нужен для всего с SDM-свичами (5350, 7628), отдельный под 3052/3352/7620/685x (по причине наличия RGMII и hwnat), отдельный под 762x (по причине наличия QDMA и нескольких GMAC на одном PDMA).
Тогда это будет более-менее нормальная поддержка.

anonymous
()
Ответ на: комментарий от intelfx

Опять взял и обосрал еще одного человека, который между прочим коммитит в vanilla: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=ne...
А OpenWRT что, манна небесная, что туда каждый ядерщик должен лезть и правдами-неправдами стремиться пропихивать свой код и идеи? Я вот туда не хочу коммитить, потому что мне не нравится сам принцип построения системы. И Padavan тоже не хочет.
OpenWRT вообще не для роутерных задач прошивки делает (хотя и делает вид, и многие пытаются их так использовать), а скорее general-purpose linux для embedded. Это у них нормально получается, не спорю. Сам использую когда нужно самоделки завести какие-то на embedded, или встраиваемый дистрибутив (для ip-камер например).
Но именно как роутер, маршрутизатор или точку доступа не использую OpenWRT нигде и не использовал никогда - есть намного лучшие варианты.
Насчет peer review - так иди и помогай с review. Там на bitbucket есть небольшая команда разработчиков, с которой и происходит общение. Всем хватает.
А вообще peer review из OpenWRT тобой очень переоценен, о чем свидетельствует почти каждый второй коммит по обновлению версий компонентов: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=066c85321ee00628662... (дословно: мужики, я тут собрал, оно типо собралось и даже на моей одной железке типа запустилось, коммичу нах). Очень напыщенное название для процесса обычной наколенной разработки.

anonymous
()
Ответ на: комментарий от anonymous

mi router 3g не имеет никакого отношения к 3G ;)

devl547 ★★★★★
()
Ответ на: комментарий от NiTr0

как анонимус выше написал - лютый бред.

Куда ребятам из Гугла и IETF до анонимусов с ЛОРа.
Бьются бедные несколько лет, проблемы фиксят. А анон говорит, что и не было ничего.

devl547 ★★★★★
()
Ответ на: комментарий от anonymous

Опять взял и обосрал еще одного человека, который между прочим коммитит в vanilla

Один коммит в tools/

В целом, это и есть «ноунейм». Я не пытаюсь никого обосрать.

А OpenWRT что, манна небесная, что туда каждый ядерщик должен лезть и правдами-неправдами стремиться пропихивать свой код и идеи?

Хорошо. Забудем про OpenWRT. Хотя бы в mainline. Суть моих претензий к «прошивке от Падавана» не изменяется: это всё равно огороженная песочница одного человека.

peer review из OpenWRT тобой очень переоценен, о чем свидетельствует почти каждый второй коммит по обновлению версий компонентов
(дословно: мужики, я тут собрал, оно типо собралось и даже на моей одной железке типа запустилось, коммичу нах)

А зачем нужно больше внимания к банальному бампу версии прикладного пакета?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от devl547

вы-то можете объяснить, откуда bufferbloat может взяться приаппаратном перекладывании пакетов с правкой заголовков из порта в порт??? и почему его нет при л3 роутинге но вдруг чудом вылазит при нате???

NiTr0 ★★★★★
()
Ответ на: комментарий от devl547

Не надо путать пути обработки трафика в железе и программно в ядре linux. Это две _колоссальные_ разницы.
В случае с hwnat роутер по уровню буферизации не больше, чем любой тупой store-and-forward свитч, к которому никто претензий и не предъявляет.

anonymous
()
Ответ на: комментарий от intelfx

А зачем нужно больше внимания к банальному бампу версии прикладного пакета?

Тогда что такое вообще peer review и зачем оно нахрен нужно? В каких случаях?

anonymous
()
Ответ на: комментарий от NiTr0

При l3-роутинге через стандартный путь в linux он есть - как минимум есть очередь napi из еще необработанных rx-дескрипторов в DMA, затем очередь на rcv-backlog, затем очередь на tx-queue с дисциплиной на интерфейсе, затем на еще неоправленные tx-дескрипторы уже в DMA. В случае с ppp все еще хуже. И да, здесь есть проблемы, и да, с ними борятся разными средствами.
Вот только народ тут слабо понимает как вообще идет трафик в роутерах, и что при работе hwnat этого всего он даже не достигает - он еще на уровне свича улетает обратно.

anonymous
()
Ответ на: комментарий от anonymous

В случае с hwnat роутер по уровню буферизации не больше, чем любой тупой store-and-forward свитч

Погоди, а давно QoS и AQM научились делать с hwnat?

devl547 ★★★★★
()
Ответ на: комментарий от anonymous

дык мы вроде как об аппаратном роутинге/нате говорили.

NiTr0 ★★★★★
()
Ответ на: комментарий от devl547

Погоди, а давно QoS и AQM научились делать с hwnat?

QoS - там полисинг. который, к слову, в сохо роутерах мало кто юзает - ибо ненужно.

AQM - какой такой queue management, если очереди НЕТ???

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

Такое чувство, что для тебя роутер - это коробка, который один tcp поток от единственного отправителя перекладывает в апстрим.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

почему - один поток, от одного отправителя? много потоков, от многих отправителей. но - да, перекладываются в апстрим и обратно, почти мгновенно (некоторые пакеты таки проходят через проц - для обеспечения кой-какого stateful).

нафига локальный qos в домашней мыльничке непонятно (торренты можно и на самом клиенте прикрутить). а вот зачем ему уметь молотить несколько сот мбит торрента - таки вполне понятно.

NiTr0 ★★★★★
()
Последнее исправление: NiTr0 (всего исправлений: 1)
Ответ на: комментарий от devl547

7621 при работе через qdma умеет аппаратные очереди qos.
Опять таки, при работе hwnat поведение не отличается от store&forward свитча - где там очереди, которым нужно активное управление?
Да, количество tcp flow может быть под десяток тысяч, но каждый входящий ethernet-кадр аппаратно парсится и вычисляется его хэш по нужным смещениям, мгновенно по этому хэшу аппаратно находится FoE-запись, в которой прописано как и что менять, и согласно этой FoE-записи пакет быстро реврайтится, пересчитываются в нужных местах чексуммы и он тут же улетает в порт свитча. В такой схеме плевать на количество потоков, главное чтобы хэш был получше и размер аппартной FoE-таблицы был подходящим.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.