KorDen

https://help.keenetic.net/hc/ru/articles/115001054729-Установка-IP-АТС-Asterisk-11-на-интернет-центр-Keenetic Флешка/HDD таки требуется.

С винды "ping -l 1472 -f 11.22.33.44", с линукса ping -M do -s 1472 11.22.33.44 (в Entware у пинга из бизибокса такого параметра нет) - ходят пакеты через сетевушку?

That's it. Но без него проц уходит в полку на DL=61 / UL=85 При маршрутизации без NAT получается DL=66 / UL=112, проц опять 100% Сбриджевал AsixEthernet0 в Home, сюрприз - не проходят пакеты больше 1470 байт, кто-то два байта съел. Edit: как-то я в прошлый раз похоже странно пинговал, вроде как и с NAT выше 1470 не ходят. Поставил ради интереса принудительно mtu 1498 - с ppe лучше не стало

@vasek00, @Sort44, со скоростью творятся крайне странные вещи. (гигабитный канал с ультры) - AX88179->Extra II - ноут с 11ac Сайты грузятся как-то через раз, показометр beta.speedtest.net - DL 0.12 Mbps, UL 158.64 Mbps 1472 пакеты ходят, т.е. проблема не в MTU. Предположив что проблема в DL, копирую по самбе с вышестоящей сетки тяжелый файл - cтабильные 17 МБ/с в одну сторону, в дуплексе получается тоже суммарно не выше порядка 18 МБ/с (т.е. приблизительно 9+9 МБ/с)

Воткнул ради интереса ориковский USB-3.0 хаб с гигабитным Ethernet (определяется как AX88179). Раньше просто находило девайс и на этом заканчивалось, register 'asix' и подобного вообще не было. Сейчас стал определяться: [I] Nov 4 00:27:10 ndm: kernel: usb 1-2.1: new high-speed USB device number 3 using xhci-hcd [I] Nov 4 00:27:10 ndm: kernel: usb 1-2.1: New USB device found, idVendor=0b95, idProduct=1790 [I] Nov 4 00:27:10 ndm: kernel: usb 1-2.1: Product: AX88179 [I] Nov 4 00:27:10 ndm: kernel: usb 1-2.1: Manufacturer: ASIX Elec. Corp. [I] Nov 4 00:27:10 ndm: kernel: usb 1-2.1: SerialNumber: 00000000000084 [I] Nov 4 00:27:10 ndm: kernel: ax88179_178a 1-2.1:1.0: eth0: register 'ax88179_178a' at usb-xhci-hcd-2.1, ASIX AX88179 USB 3.0 Gigabit Ethernet, <...> [I] Nov 4 00:27:11 ndm: Network::Interface::Base: "AsixEthernet0": interface is down. [I] Nov 4 00:27:11 ndm: Network::Interface::Base: "AsixEthernet0": interface is up. [I] Nov 4 00:27:11 ndm: Network::Interface::Repository: "AsixEthernet0" interface created. [I] Nov 4 00:27:11 ndm: Network::Interface::Usb: "AsixEthernet0": interface "AsixEthernet0" is plugged (port 1). [I] Nov 4 00:27:11 ndm: Network::Interface::Base: "AsixEthernet0": description saved. [I] Nov 4 00:29:10 ndm: kernel: ax88179_178a 1-2.1:1.0: eth0: ax88179 - Link status is: 1 Реальную работоспособность пока не проверял, надо будет поиграться, насколько реально получить больше сотни на Extra II...

Ultra II, наблюдаю ситуацию достаточно давно (и как бы не на Giga II еще, но не видел): nf_conntrack_count порядка 1000, трассировка нормальная: Трассировка маршрута к ya.ru [87.250.250.242] с максимальным числом прыжков 30: 1 <1 мс <1 мс <1 мс KU2 [192.168.0.1] 2 1 ms 1 ms 1 ms ......... ..... Нагружаем торрентами, conntrack >2000, в трассировке начинаются странности на роутере Трассировка маршрута к ya.ru [87.250.250.242] с максимальным числом прыжков 30: 1 * <1 мс * KU2 [192.168.0.1] 2 1 ms 1 ms 1 ms ....... Пинг до роутера без потерь, в целом все работает без проблем, но такая трассировка напрягает.

Можно ожидать сохранения телефонной книги на флешке до обновлений вебки? Ведь сейчас уже есть папка для истории и в ней один-единственный файлик - положить бы рядом файлик с телефонной книгой и все было бы прекрасно.. Ну или команду для задания пути для тел.книги в CLI. А номера пока можно и с трубки вбить - они ведь сейчас уже вбиваются, только не сохраняются при перезагрузке...

В копилку трубок, но отрицательную: Panasonic KX-TGA161RU (база KX-TG1611RU / KX-TG1612RU) не удается зарегистировать (трубка не видит базу при регистрации). Замечу, что она так же не регается и в DECT-сети (Aastra IPBS), в интернете нашел похожие жалобы со Spectralink KIRK. Похоже, можно заносить в список несовместимых/нерекомендуемых

Я уже забыл, когда переходил файлами, после того как узнал про components list draft (delta)

Поднимите взгляд прямо в этой теме повыше

В очередной раз забыв, какой порт куда ведет, опять вспомнил об этом. На текущий момент description портов для сегментов видно только в CLI, rename в старом интерфейсе "ломает" порт: А в новом ломает все отображение портов вовсе. Хотелось бы видеть пользовательское название порта из rename или description вместо номера порта в web-интерфейсе. В идеале все же rename, чтобы иметь возможность обращаться к порту по имени в CLI, но если это что-то ломает - тогда уж description.

Кстати, говоря о цели уведомлений чисто чтобы знать на каком канале сейчас - это штатно может отображаться индикатором FN на роутере

а интерфейсы private/public где как? за тесты спасибо, попробую тогда все же у себя вместе с тестированием фрагментирования EoIP заодно и это проверить.

Речь не про хопы в туннеле. Например, я заворачиваю трафик до 8.8.8.8 в туннель (или даже банально ip global, т.е. как интернет-подключение). С локальной сети, скажем, трассировка выглядит условно так: 192.168.0.1 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5 6.6.6.6 7.7.7.7 8.8.8.8 С удаленной сети это выглядит условно так: 192.168.1.1 * * * (должно быть 192.168.0.1 или туннельный интерфейс 192.168.255.2) * * * * * * * * * 4.4.4.4 5.5.5.5 6.6.6.6 7.7.7.7 8.8.8.8 Т.е. вроде количество хопов +1, но почему-то первые 4 после локального роутера - пропуски. А может вообще вся трассировка обрывается после локального роутера.

Да, первый хоп (локальный роутер) проходит, со второго обрывается, но в паре случаев (если маршрут уходит в WAN с кучей хопов) видел что с этак пятого узла начинается нормальная трассировка (за вычетом пропущенных хопов).

Для этого есть opkg. Вставляете флешку, ставите на нее entware, кидаете скрипт с нужными действиями в /opt/ets/ndm/wan.d/ и хоть на имейл, хоть в телеграм, хоть на сирену через подключенную к роутеру звуковушку xD Флешка должна быть всегда воткнута. Если выткнуть, или она сдохнет - роутер продолжит работу, но уже без фич, что были на ней типа уведомлений

Ага. А еще, если рассматривать 5GHz-устройства, то там отдельный клиент для 2.4 и 5, ну т.е. можно на одного соседа по пятерке зацепиться, на другого по двойке Пара-тройка проводных каналов с горстью 4G-модемов при этом никуда не деваются. Но и сидеть приходится на каналах соседа, что может быть не очень хорошо (сильно зависит от местности конечно) Было время, делал мегосхему (ну как, все достаточно банально) на Giga II из двух проводных провайдеров и двух модемов с пингами каждые 2 секунды кажется. Плюс рядом в качестве холодного резерва лежал Keenetic 1 с аналогичным конфигом - простой должен был быть минимальным, все были обучены на быстрое перетыкание. В боевом режиме реально только раз перешло на другого проводного провайдера, модемы не понадобились, хотя тестировалась имитация падения и того и другого. Необходимость минимального простоя была только в течение этак месяца, поэтому смысла покупать дорогие железки с горячим резервированием 1+1 всего и вся не было. Одно плохо - нет возможности переходить по порогу потерь или заданному таймауту пинга, для ситуаций когда интернет вроде есть, но очень фиговый (сильные потери или аномально высокий пинг) - но на этот случай можно просто выдернуть кабель или выключить в вебке интерфейс.

Со времен этой темы уже давно в новых прошивках возможно задавать все необходимые опции в штатном прошивочном DHCP

Вопрос к тем, кто использует IPIP. Вроде @r13, и возможно еще кто-то.. У вас ходит трассировка через туннель? Раньше как-то специально не разбирался, а теперь понимаю, что хотя все работает и пинги ходят (в том числе пинг IP туннельного интерфейса удаленной стороны), трассировка обрывается на ближайшем роутере и до удаленной стороны пакеты не добираются вообще. Один линк роутер-роутер, другой линк роутер-Linux (Strongswan + ip tunnel), в обоих случаях одинаково - по tcpdump на приходящем интерфейсе в этот момент ничего нет. Т.е.: имеем линк IPIP (192.168.0.1/24) [192.168.255.1/30]---[192.168.255.2/30](192.168.1.1/24). Со 192.168.0.2 пингуется 192.168.255.2 и все удаленные узлы и проблем нет, но если сделать трассировку до чего либо, на интерфейсе 192.168.255.1 уходящий icmp видно, на 192.168.255.2 тишина, трассировка соответственно не идет дальше 192.168.0.1 ICMP пробовал специально на всех интерфейсах разрешать, толку нет. private/protected/public - значения не имеет.

Эээм, а какие еще параметры, кроме reg-timeout, нужны? registration-retry как я понимаю юзается только при неуспешной регистрации, а других похожих параметров я не вижу.

Даешь policy-based routing! С verify-availability и прочими even-odd.

Локальные сервисы ходят через прошивочный сервер (он ведь остается в rpc-режиме). Если в DNS-серверах роутера прописать локальный IP самого же роутера и запретить получение DNS от провайдера (ip dhcp client no name-servers), или вручную их прописать только для резолвинга имен сервера подключения например, с указанием домена - роутуер будет ходить на локальный сервер: (config)> show ip name-server server: address: 192.168.0.1 domain: global: 0 (config)> tools ping www.google-analytics.com sending ICMP ECHO request to www.google-analytics.com... PING www.google-analytics.com (0.0.0.0) 56 (84) bytes of data. 84 bytes from www.google-analytics.com (127.0.0.1): icmp_req=1, ttl=64, time=0.41 ms. --- www.google-analytics.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss, 0 duplicate(s), time 600.33 ms. Round-trip min/avg/max = 0.41/0.41/0.41 ms.

Похоже, разобрался. Если при создании дефолтного маршрута не указывать интерфейс (т.е. оставить "любой"), то оно как бы добавляет 0.0.0.0/0 via 192.168.0.1, и в таблице маршрутов корректно отображает что маршрут через Home, но при этом обновления не работают: [I] Jan 1 03:02:01 ndm: Dns::Manager: name server 192.168.0.1 added, domain (default). [I] Jan 1 03:02:01 ndm: Core::ConfigurationSaver: saving configuration... [I] Jan 1 03:02:05 ndm: Core::ConfigurationSaver: configuration saved. [I] Jan 1 03:02:06 ndm: Network::RoutingTable: added static route: 0.0.0.0/0 via 192.168.0.1. [I] Jan 1 03:02:06 ndm: Core::ConfigurationSaver: saving configuration... [E] Jan 1 03:02:08 ndm: Core::Ndss: [406] no internet connection. [E] Jan 1 03:02:24 ndm: Core::Ndss: [524] no internet connection. [I] Oct 21 11:28:52 ndm: Core::System::Clock: system time has been changed. [I] Oct 21 11:28:52 ndm: Ntp::Client: time synchronized with "3.pool.ntp.org". [E] Oct 21 11:28:53 ndm: Core::Ndss: [545] no internet connection. А вот если указывать интерфейс Home - тогда обновления работают. Причем похоже если туда-сюда переключать без ребута, то начинаются странности, я тогда вначале добавил через "любой", а затем изменил на "Home", но оно все равно ругалось. А сейчас вроде воспроизвести не получилось, все работает.

А вот кстати интересно. DNS-то добавлен, и маршрут похоже таки работает: (config)> tools ping ndss.11.zyxel.ndmsystems.com sending ICMP ECHO request to ndss.11.zyxel.ndmsystems.com... PING ndss.11.zyxel.ndmsystems.com (88.198.177.100) 56 (84) bytes of data. 84 bytes from ndss.11.zyxel.ndmsystems.com (88.198.177.100): icmp_req=1, ttl=50, time=54.86 ms. 84 bytes from ndss.11.zyxel.ndmsystems.com (88.198.177.100): icmp_req=2, ttl=50, time=54.25 ms. --- ndss.11.zyxel.ndmsystems.com ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss, 0 duplicate(s), time 1654.51 ms. Round-trip min/avg/max = 54.25/54.55/54.86 ms. (config)> components preview preview: Core::Ndss error[9240615]: [507] no internet connection. И я ведь совсем забыл - время-то устанавливается по NTP.. Т.е. походу это чисто бага апдейтера...

Режимы работы а-ля ТД и прочие репитеры-клиенты урезают слишком много функционала, поэтому ТД работает в режиме роутер, но с отключенным ISP, DHCP и NAT. Однако в таком виде сам роутер не может связаться с интернетом для обновлений и прочего, а добавление настоящего шлюза ничего не дает, т.к. Home у нас не global. Как можно заставить сам роутер в режиме роутера ходить на шлюз в сети Home? Это же касается и бриджевания EoIP в Home. Edit: похоже, только обновление компонентов ругается на отсутствие интернета (Core::Ndss error[9240615]: [507] no internet connection), при этом время по NTP синхронизируется, пинг того же ndss проходит.