Важно, что в один момент времени один Wi-Fi чип может работать только в одном диапазоне. Если же ваша точка доступа утверждает, что может работать в двух одновременно, как например, делают бесплатные роутеры от популярных провайдерах Virgin или British Telecom, значит в ней на самом деле два чипа.
Это откровенная неправда, например посмотрите на DBDC режим в чипе MT7615 от MediaTek. Он умеет 4T4R в любом из диапазонов (2,4 или 5) или же делится виртуально пополам на 2T2R в 2,4 и 2T2R в 5 ГГц, хотя чип один.
И это только MediaTek, у Qualcomm и Broadcom тоже есть аналогичные чипы.
Сочетание символов «DIR-620» не говорит вообще ни о чем, кроме того, что это устройство с 2 MIMO WiFi антеннами и USB-портом.
Ревизия-то какая? Русская прошивка или нет?
Обязательно стал бы.
Сейчас все провайдеры поголовно используют spirent для тестирования, а пройти его без аппаратного ната практически невозможно.
А провайдерский кастомный рынок — основной для dlink.
ZyXEL Keenetic Ultra II мало того, что поддерживает 16384 сессий в аппаратном NAT (который работает на уровне гигабитного свича, то есть сетевые карты устройства даже не видят обрабатываемых им пакетов кроме keep-alive и некоторых специфичных навроде TCP SYN/RST), так и имеет два уровня программного ускорения обработки трафика: на одном из них пакеты обрабатываются и отправляются сразу в контексте NAPI сетевой карты, полностью минуя весь сетевой стек, в другом минуют весь путь через netfilter, проходя от цепочки PREROUTING сразу в POSTROUTING.
В последних двух режимах полностью поддерживается шейпер и приоритезация, а также ускорение PPPoE/PPTP/L2TP-туннелей.
Плюс ко всему он имеет 256 Мбайт DDR2 и два ядра по 880 МГц, и в теории размер conntrack-таблицы неограничен.
Ну и напоследок: компонент IPsec в сочетании с аппаратным обработчиком ESP пакетов позволяет прокачивать до 350 Мбит/сек в режиме ESP AES/SHA1.
На фоне этого предложенные здесь Cisco с точки зрения именно скорости являются странным выбором.
А еще проще 3272 и 3276 просто перешить в HiLink и в его веб-морде указать все настройки.
При этом модем будет определяться как USB CDC и скорость будет выше, чем в RAS-режиме.
PPTP сервер умеет уже несколько лет (NDMS 2, компонент VPN Server), очень скоро подтянется IPsec в разных видах.
EoIP кстати реализовать элементарно — было бы желание, только запросов от клиентов нет.
Кстати я даже не знаю что страшнее в случае с MITM — потерять учетные данные доступа к инету, или же сам интернет-трафик. Потому что даже в случае SuperCHAPv100500 клиент будет авторизован, и весь его трафик можно спокойно слушать в пассивном режиме — достаточно взять 2 сетевухи, поставить linux, добавить их обе в bridge (его надо поднять, но без адреса и запретить ARP) — и никто не заметит этот пассивный сниффер.
MITM разумеется никто не отменял, каждый раз проходя в подъезде мимо своего кабеля ethernet, висящего голым до распаечной коробки становится как-то стремновато :)
Ростелеком в Мордовии (про другие регионы не могу сказать) для PPPoE предлагает только PAP, и похоже так будет продолжаться еще неизвестно сколько времени. Правда они что-то там мутили с qinq, привязкой mac адресов и логина/пароля от интернета к порту на свиче доступа, а также учетные данные доступа в личный кабинет отличаются от таковых для доступа в интернет, так что атаку из поста реализовать будет не так просто.
Кстати достаточно было еще до habracut написать, что данное устройство на основе чипа rt5350: для роутерщиков это единственный интересный момент во всей статье, потому что практически любой 5350 с uboot можно зашить в openwrt. :)
Ядро Linux разрабатывается как легко переносимое, потому у него нет жестких завязок на хардварные таймеры (если вы их сами не прикрутите).
То, что здесь названо CONFIG_HZ — это исторический системный таймер, к которому привязан счетчик jiffies, планировщик и классические struct timer. Он платформонезависим, а изменение значения jiffies с изменением реального времени связно при помощи соотношения dT (sec) = djiffies / CONFIG_HZ.
Да, исторически ядро всегда дергалось аппаратным прерыванием с константным рейтом раз в 1/CONFIG_HZ миллисекунд чтобы вызвать планировщик, произвести необходимые отложенные операции (например с RCU), а также обработать сработавшие struct timer, потому что это просто и переносимо. Плюс раньше процессоры были слабые, и обработка прерывания даже раз в 1 мс уже была слишком дорогой, а перепрограммировать системный таймер раз в прерывание тоже было дорого.
Но мощь ЦПУ роста, и со временем некоторым (как и вам) все больше и больше не нравилась постоянная обработка бесполезных прерываний аппаратного таймера (а заметная часть их бесполезна, особенно при малом количестве процессов в системе и отсутствии необходимости в обработке множества bottom-halves, tasklets и workqueues при низкой нагрузке на систему), потому придумали так называемый tickless-режим, задаваемый опцией CONFIG_NO_HZ (а старый обозвали FULL_HZ соответственно), в котором прерывания от аппаратного таймера включаются тогда, когда они нужны и хардварный таймер регулярно меняет рейт (подробное описание всех вариаций режима займет много времени, проще погуглить по «linux kernel tickless», идеальное начало тут: git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/NO_HZ.txt ); другим же товарищам стало мало точности в 1/CONFIG_HZ (реально, по меркам большинства подсистем ядра, особенно при современной мощности ЦПУ и сетевых картах в 40 GBps это целая вечность), потому ввели поддержку High-Precision Event Timers и новых struct hrtimer (High-Resolution Timers) с точностью вплоть до 1 нс.
Так что все течет, все меняется, и утверждения из комментария можно считать справедливыми разве что для ядер < 2.6 (и соответственно для 2003 года и раньше). Ну и на 2.4 вообще имхо сейчас стоит смотреть разве что с археологическими целями — тот же планировщик процессов в цикле разработки 2.6 был переписан неоднократно, его разработка постоянно приковывала к себе внимание и вызывала жаркие дискуссии.
Ну и кстати просто делать IPv4 NAPT это очень тупо и неинтересно, сейчас все более-менее массовые и дешевые чипы для CPE это делают (включая RTL8196x, MT762x, RT6xxxx и Broadcom). А вот как дело обстоит с L2TP / PPPoE / GRE?
Можно использовать фемтосоту (они как правило умеют только GSM/UMTS, но у вас и так WiFi будет для доступа к Интернету).
Это откровенная неправда, например посмотрите на DBDC режим в чипе MT7615 от MediaTek. Он умеет 4T4R в любом из диапазонов (2,4 или 5) или же делится виртуально пополам на 2T2R в 2,4 и 2T2R в 5 ГГц, хотя чип один.
И это только MediaTek, у Qualcomm и Broadcom тоже есть аналогичные чипы.
Ревизия-то какая? Русская прошивка или нет?
Пока неизвестно, подобные решения о выпуске устройств для других стран принимает руководство в Тайване, но они еще думают.
Сейчас все провайдеры поголовно используют spirent для тестирования, а пройти его без аппаратного ната практически невозможно.
А провайдерский кастомный рынок — основной для dlink.
В последних двух режимах полностью поддерживается шейпер и приоритезация, а также ускорение PPPoE/PPTP/L2TP-туннелей.
Плюс ко всему он имеет 256 Мбайт DDR2 и два ядра по 880 МГц, и в теории размер conntrack-таблицы неограничен.
Ну и напоследок: компонент IPsec в сочетании с аппаратным обработчиком ESP пакетов позволяет прокачивать до 350 Мбит/сек в режиме ESP AES/SHA1.
На фоне этого предложенные здесь Cisco с точки зрения именно скорости являются странным выбором.
То есть 100,4 МГц.
При этом модем будет определяться как USB CDC и скорость будет выше, чем в RAS-режиме.
+1
EoIP кстати реализовать элементарно — было бы желание, только запросов от клиентов нет.
То, что здесь названо CONFIG_HZ — это исторический системный таймер, к которому привязан счетчик jiffies, планировщик и классические struct timer. Он платформонезависим, а изменение значения jiffies с изменением реального времени связно при помощи соотношения dT (sec) = djiffies / CONFIG_HZ.
Да, исторически ядро всегда дергалось аппаратным прерыванием с константным рейтом раз в 1/CONFIG_HZ миллисекунд чтобы вызвать планировщик, произвести необходимые отложенные операции (например с RCU), а также обработать сработавшие struct timer, потому что это просто и переносимо. Плюс раньше процессоры были слабые, и обработка прерывания даже раз в 1 мс уже была слишком дорогой, а перепрограммировать системный таймер раз в прерывание тоже было дорого.
Но мощь ЦПУ роста, и со временем некоторым (как и вам) все больше и больше не нравилась постоянная обработка бесполезных прерываний аппаратного таймера (а заметная часть их бесполезна, особенно при малом количестве процессов в системе и отсутствии необходимости в обработке множества bottom-halves, tasklets и workqueues при низкой нагрузке на систему), потому придумали так называемый tickless-режим, задаваемый опцией CONFIG_NO_HZ (а старый обозвали FULL_HZ соответственно), в котором прерывания от аппаратного таймера включаются тогда, когда они нужны и хардварный таймер регулярно меняет рейт (подробное описание всех вариаций режима займет много времени, проще погуглить по «linux kernel tickless», идеальное начало тут: git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/NO_HZ.txt ); другим же товарищам стало мало точности в 1/CONFIG_HZ (реально, по меркам большинства подсистем ядра, особенно при современной мощности ЦПУ и сетевых картах в 40 GBps это целая вечность), потому ввели поддержку High-Precision Event Timers и новых struct hrtimer (High-Resolution Timers) с точностью вплоть до 1 нс.
Так что все течет, все меняется, и утверждения из комментария можно считать справедливыми разве что для ядер < 2.6 (и соответственно для 2003 года и раньше). Ну и на 2.4 вообще имхо сейчас стоит смотреть разве что с археологическими целями — тот же планировщик процессов в цикле разработки 2.6 был переписан неоднократно, его разработка постоянно приковывала к себе внимание и вызывала жаркие дискуссии.