colimp

Делал такое на pptp, все подсети друг-друга видят. В туннель трафик направляется согласно прописанных маршрутов. В инет все ходят через местных провайдеров.

К сожалению, не завелась. Все тот же циклический ребут.

У меня не завелась, к сожалению. Циклический ребут.

Да, все компоненты с WiFi убрал. По ссылке минимальный набор, мне бы с openvpn и opkg. Или всем кроме WiFi - флешка у GigaII достаточно большая.

Не сработало. Аналогичная проблема с Giga II. Неделю назад периодически стал отваливаться WiFi, в логах были ошибки драйвера, после перезагрузки роутера все восстанавливалось. И вот вчера он ушёл в циклический ребут. Keenetic Recovery прошивает без проблем, но в итоге получаю все тот же циклический ребут. Нашёл прошивку 1.11, подменил файл, и роутер стартанул, но его WiFi-сеть устройства не видят. Второй такой же Giga II здоровый. Обновил прошивку, предварительно сняв галочку с Интерфейса WiFi, скачал её и залил в первый роутер - все равно циклический ребут. Собственно вопрос, нельзя ли отключить проверку работоспособности интерфейса, если и без действующего WiFi работа остальных компонентов возможна, как показала прошивка 1.11? И не осталось ли у кого-нибудь прошивки 2.02 для Giga II?

Прошивка одна из последних линейки 2.10, точнее завтра смогу посмотреть. Расстояние до Root-AP напрямую метров 15, но через 3-4 жб-перекрытия (сигнал -72 дБ). Планшет без проблем подключается и выдаёт 11/13 Мбит/с. От клиентов до AP Keenetic при замерах было 1-2 метра. AP Keenetic в той же точке, в которой замерялась скорость с планшета до Root AP. Скорость у клиентов 1/3 Мбит/с. На Root AP никаких ограничений нет. На WISP-клиенте WEP-шифрование, на AP Keenetic WPA2. Год назад WISP работал от Open-сети Dir-300, далее в WPA2, и тогда скорости Keenetic-LAN совпадали с прямым подключением планшета к Dir-300.

Немного предыстории. Ранее пользовался WISP с роутера Dir-300 в режиме 802.11n, сигнал через две стены был средний, на LAN скорость была ~40 Мбит/с, у WI-FI-клиентов ~20 Мбит/с, что вполне логично, так как беспроводной канал делится пополам. Сегодня понадобилось поднять WISP от роутера Tp-Link, работающего в режиме 802.11g (wep). Планшет и телефон цепляются к этому роутеру (сигнал в районе -72дБ), спидтест выдаёт 11/13 Мбит/с (down/up), но когда ставлю в это же место Giga II (антенны 2х5dBi) и через WISP цепляюсь к Tp-Link, то у Wi-Fi-клиентов спидтест показывает 1/3 Мбит/с, то есть падение скорости во много раз. Померил через LAN, скорость 1.8/4 Мбит/с. Почему так? В веб-интерфейсе сигнал 2-3 палки, режимы принудительно выставлял и 802.11gn, и 802.11 bg. Телефоны и планшеты с примитивными антеннами выдают 11/13 Мбит/с.

Не менял, вечером попробую. С UsbModem тоже acl не трогал, но правила работали. До сегодня считал, что они в обе стороны действуют. Спасибо за подсказку. Я через веб-интерфейс вносил, это сам роутер в конфиг так занёс.

Столкнулся с проблемой: игнорируются правила МСЭ на интерфейсах WifiMaster0/WifiStation0 и CdcEthernet0. Цель: разрешить tcp, udp для одного ip и заблокировать все остальные ip. Несмотря на последние записи в access-list соответствующего интерфейса deny tcp 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 deny udp 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 deny icmp 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 пакеты уходят в любые направления. Роутер, конечно, перезагружал. Год назад такое проделывал с UsbModem0 - все работало. Giga II и Omni II, 2.09.A.6.0-0

Не знал про эту особенность. В инструкции этот момент тоже пропущен. Спасибо за подсказку!

Уже голову сломал, читал конфиг построчно на предмет конфликтов, ничего не нашёл. Проблема следующая: есть подключенные pptp-клиенты: Добавляю статическую маршрутизацию (все по инструкции ): В логах все отлично добавляется, ошибок нет, в конфиге эти строки тоже сохранены: Но в маршрутах их нет, и трассировка до клиентского роутера 192.168.2.1 все равно идёт через WAN: В чем ошибка? Когда пользовался этим функционалом (ещё на 2.08 прошивке), все работало. Где что я мог сломать? Куда смотреть?

Большое спасибо! Никогда не пользовался этой кнопкой, считал её аналогом программного включения/отключения wi-fi в вебморде. Со второго нажатия светодиод загорелся, wi-fi заработал!

Нет индикации светодиода Wi-Fi, клиенты не видят Wi-Fi- сеть, в WISP бесконечно крутится ромашка. Прошивка была последняя draft 2.08. Сброс на заводские настройки и установка последней 2.09 результата не принесли. В логах есть записи: Аппаратная неисправность? Сейчас добавлю self-test.

Суть проблемы (для всех версий): снаружи невозможно подсоединиться через резервное подключение роутера (IPoE, имеет белый IP). Если сделать его основным, то все прекрасно работает., По резервному каналу роутер снаружи даже не пингуется, не говоря уже о подключении pptp-клиентов. В то же время исходящие соединения прекрасно работают, если маршрут до нужного узла указывать через этот резервный канал, однако это правило все равно не позволяет удаленному узлу подключиться к роутеру через его резервный канал. Как быть? Giga II.

Еще забыл добавить, что после данных действий у меня отвалился один из pptp-клиентов на v2.08. Подключается и тут же разрывается. Диапазоны не пересекаются, для pptp используется 172.16.1.Х. Клиент с 2.07 работает нормально на соседнем IP. upd: Проблему решил установкой компонента IPv6. С pptp проблема тоже ушла.

С последними пунктами варианта 2 возникли проблемы. На команды iptables -t nat -A PREROUTING -i ra2 -p udp --dport 53 -j REDIRECT --to-ports 9053 iptables -t nat -A PREROUTING -i ra2 -p tcp --syn -j REDIRECT --to-ports 9040 приходит ответ: Nov 04 08:54:22ndmOpkg::Manager: /opt/etc/ndm/netfilter.d/010-tor-net.sh: iptables: No chain/target/match by that name. Nov 04 08:54:22ndmOpkg::Manager: /opt/etc/ndm/netfilter.d/010-tor-net.sh: exit code 1. Сам tor работает, потому в браузере можно использовать socks5-прокси (192.168.10.1:9100), а вот проброс iptables ругается. Еще в журнале часто встречаются сообщения: pptpd[493]MGR: dropped small initial connection Giga II, Entware-3x, v2.08(AAFS.2)A9

Сделать псевдо multiwan довольно просто. По крайней мере торренты будут качаться сразу со всех интерфейсов. В #broadband.globals на вкладке "Дополнительно" можно задавать статические маршруты через интерфейсы, находящиеся в резерве. И мы там видим, что можно задать маршрут как до узла, так и до сети. Смотрим маски и находим 240.0.0.0. То есть весь диапазон IPv4 можно разбить на 16 участков с помощью этой маски. Итого надо внести всего 8 записей с такой маской и указать интерфейс резервного канала, через который пойдёт трафик. Диапазоны с такой маской нарезаются подобным образом: Первый 0.0.0.0-15.255.255.255, второй 16.0.0.0-31.255.255.255 и т.д. Я бы сразу исключил диапазоны, в которых встречаются IP, зарезервированные для локальных сетей во избежание накладок: 10.0.0.0 — 10.255.255.255 172.16.0.0 — 172.31.255.255 192.168.0.0 — 192.168.255.255 Перенаправляем трафик через резервное подключение, к примеру: 64.0.0.0 mask 240.0.0.0 80.0.0.0 mask 240.0.0.0 и т.п. P2p-подключения более менее равномерно распределены по всему диапазону IPv4: одна часть пойдёт по умолчанию через основное подключение, другая часть попадёт под ваши правила и отправится в резервный канал.