Александр Рыжов

У меня после перезагрузки Ultra II (а перегружается она до-о-олго) плееры WD TV Live сообщают об отсутствии сети. Передёргивание сетевого кабеля плеера решает проблему. Возможно, дело во внешнем свитче Ultra II: свитч остаётся включенным во время перезагрузки роутера, а клиенты за это время не дожидаются ответа от DHCP-службы кинетика. Готов предоставить информацию для диагностики проблемы, если это будет необходимо.

Тот же косяк, что и в первом посте:

Если установить компонент «Аппаратный обработчик пакетов» 2.6.36+4.0-18-1 на Ultra II c этой прошивкой, то pppoe-соединение начинает работать с практически нулевой скоростью: Нашёл виновника следующим образом: залил на роутер рабочий конфиг с которым всё было хорошо, перегрузил роутер, слил с него конфиг и посмотрел разницу: C:\Users\Александр\Downloads>diff.exe -u ./running-config_good.txt ./running-config_current.txt --- ./running-config_good.txt 2015-10-11 15:51:01.367445100 +0300 +++ ./running-config_current.txt 2015-10-16 20:20:32.307570600 +0300 @@ -2,7 +2,7 @@ ! $$$ Version: 2.06 ! $$$ Agent: http/ci ! $$$ Last change: Sun, 11 Oct 2015 12:50:20 GMT -! $$$ Md5 checksum: fac4d6481735a616772b3f2a071a2164 +! $$$ Md5 checksum: 063639fb5e87b410af0cc464d1e8377c system set net.ipv4.ip_forward 1 @@ -17,7 +17,7 @@ no button WLAN on hold hostname Keenetic_Ultra clock timezone Europe/Moscow - clock date 11 Oct 2015 15:50:58 + clock date 16 Oct 2015 20:20:43 domainname WORKGROUP ! ntp server 0.pool.ntp.org @@ -276,6 +276,8 @@ ip static tcp PPPoE0 80 10.9.69.4 65080 !HTTP on MBL ip static tcp PPPoE0 51413 through 51414 10.9.69.4 !Torrents on MBL (TCP) ip static udp PPPoE0 51413 through 51414 10.9.69.4 !Torrents on MBL (UDP) +ppe software +ppe hardware user admin password md5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx password nt yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy После чего снял галку с соотв. компонента и всё снова стало нормально:

Простите за повтор, решил перенести обсуждение сюда. Безуспешно пытаюсь настроить Custom DynDNS service. На закладке Интернет > DyDNS выбрал «Используемый сервис: Другой», указал нужный мне URL, но вижу, что кинетик к моему запросу добавляет строку после "?", хотя об этом я его не просил. Вот как выглядит лог с ответной стороны при нажатии кн.«Обновить» в WebUI: $ sudo grep Keenetic /var/log/nginx/access.log 5.145.255.19 - - [09/Oct/2015:16:07:18 -0400] "GET /myddns.php?hostname=myhost.domain.ru&myip=5.5.5.5 HTTP/1.0" 200 142 "-" "ZyXEL Keenetic Ultra II/v2.06(AAUX.1)A4 info@zyxel.ru" Второй косяк заключается в том, что Кинетик всё равно не выполняет обновления DynDNS ни при загрузке, ни по таймауту, заданному в CLI. К сервису Custom DynDNS он обращается только по кнопке «Обновить». В чём может быть дело? Ниже кусок из running-config: ! $$$ Model: ZyXEL Keenetic Ultra II ! $$$ Version: 2.06 … dyndns profile _WEBADMIN type custom domain myhost.domain.ru update-interval 0 days 3 minutes url https://www.myvps.ru/dyndns/myddns.php И третье, пожелание. Если уж заработает Custom DNS с указываемым пользователем URL'ом, то было бы здорово в строке запроса предусмотреть подстановочные знаки для текущего IP и hostname, например: https://www.myvps.ru/dyndns/myddns.php?ip={ip}&hostname={hostname}

Если вы хотите использовать ядерные модули, доступные для вашей прошивки, то можно их установить с помощью следующего скрипта: wget -qO - http://ndm.zyxmon.org/binaries/keenetic/installer/install-kmod.sh | sh Скрипт определяет модель вашего устройства, выкачивает и распаковывает архивы с модулями, собранными сообществом keenopt.ru: Checking available modules for kn_rf... Downloading and unpacking... The following modules was installed at /opt/lib/modules/2.6.36: input-core.ko snd-pcm.ko snd-usbmidi-lib.ko v4l2-common.ko snd-hwdep.ko snd-rawmidi.ko snd.ko videodev.ko snd-mixer-oss.ko snd-seq-device.ko soundcore.ko snd-page-alloc.ko snd-timer.ko uvcvideo.ko snd-pcm-oss.ko snd-usb-audio.ko v4l1-compat.ko Это все ядерные модули, доступные для вашего девайса. Если каких-то всё равно не хватает, обращайтесь к разработчикам прошивки. Только они имеют возможность их добавлять.

Тема сохранена по историческим соображениям. Этот способ установки сейчас не работает! Если у Вас прошивка 2.07 или старше - устанавливайте Entware-3x - http://forum.keenetic.net/topic/560-entware-3x/ Если у Вас прошивка младше 2.07 - устанавливайте Entware-keenetic - http://forum.keenetic.net/topic/221-репозиторий-entware-keenetic/ Актуальную версию инструкции и её обсуждение можно найти здесь. Ниже перечислен минимальный набор действий для использования Entware-ng на кинетиках. Требования ZyXEL Keenetic с USB-портом. Любой, кроме моделей VOX, ADSL, 4G или LTE. Прошивка с компонентом OPKG (либо бета от «14» ноября 2015г или новее либо релизная с OPKG). USB носитель с разделом ext2/ext3 и определённой меткой (в примере ниже метка entware). Инструкция по установке Подключите USB-носитель к кинетику, Зайдите на носитель по ftp или cifs, Cоздайте на разделе с меткой entware USB-носителя папку install, Скопируйте в папку install этот архив, Если у вас бета-версия прошивки с этого сайта, зайдите в CLI кинетика и выполните следующие команды: opkg disk entware opkg initrc /opt/etc/init.d/rc.unslung system configuration save Если у вас релизная прошивка с OPKG-компонентом, зайдите в веб-интерфейс кинетика и на странице «Приложения > OPKG» поставьте галку «Включить». Затем выберите из списка нужный USB-носитель, в поле «Сценарий initrc:» впишите /opt/etc/init.d/rc.unslung и нажмите кн.«Применить». Если все сделали правильно, то в системном журнале через некоторое время появится строчка Entware-ng installed!

ndm, ещё здесь, но не критично.

Кстати, $PATH в среду логичнее передавать не такой как сейчас: PATH='/bin:/sbin:/usr/bin:/usr/sbin:/opt/bin:/opt/sbin:/opt/usr/bin:/opt/usr/sbin' а такой, чтобы в первую очередь искались сторонние бинарники: PATH='/opt/bin:/opt/sbin:/opt/usr/bin:/opt/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin'

Пакеты после установки удаляются…Используется ли /tmp при распаковки этих пакетов? Т.е. не исчерпаю ли я всю RAM, если положу внутрь /opt/install/package.ipk DVD-фильм?Спрашиваю потому, что хочу подготовить для кинетиков пакет с chroot-средой Debian. Ultra II, в частности, удовлетворяет минимальным требованиям, а схожий пакет предыдущей версии был востребован ранее пользователями других роутеров. Пакет в сжатом виде получится ~40МБ.

Если не обременит, то наверное стоит, хотя бы для того, что бы посмотреть список пакетов для установки или скачать индивидуально интересующий пакет.Готово.https://www.ryzhov-al.ru/keenopt_index/ Обновляется раз в сутки.

На Entware при развёртывании Windows использовал dnsmasq + tftpd-hpa, т.к. не знаю другого TFTP-сервера, умеющего выполнять подстановку символов.ЗЫ Добавлю ради кинетиков в репозиторий dnsmasq.

К DNS-серверу, в свою очередь, со временем понадобятся ### Tunlr support server=/pandora.com/199.x.x.x server=/spotify.com/199.x.x.x или ### Using dnscrypt-proxy no-resolv server=127.0.0.1#65053 server=127.0.0.1#65054 Не верю, что всё это станут реализовывать. Лучше уж поднимать свой сервер.

Можно перекидывать DHCP-запросы серверу в LAN-сети и затем отдавать им нужные опции? ip dhcp relay server ‹address› Разумеется, в этом случае свой DHCP-сервер в LAN-сети должен брать на себя весь функционал заводского?

Так или иначе, нет возможности передать встроенному DHCP-серверу нужные опции. Всё, на что мы можем повлиять, это… (config)> ip dhcp class - DHCP class configuration pool - DHCP pool configuration host - set static lease host match - configure DHCP service relay - configure DHCP relay service

2. Экспорт LD_LIBRARY_PATH наверняка сделано потому, что в тулчейн для сбора пакетов не заложен rpath=/opt/lib. Хочу напомнить, что пути из LD_LIBRARY_PATH не заменяют rpath, а дополняют его подстановкой перед путями из rpath, что для без указания правильного префикса /opt не имеет смысла для ряда пакетов, использующих свои плагины (poptop, znc, perl и другие). Устанавливай LD_LIBRARY_PATH или нет, такие пакеты без правки префикса не взлетят: admin@RT-N66U:/tmp/home/root# ldd /opt/bin/perl libperl.so => /opt/lib/perl5/5.22/CORE/libperl.so (0x2aac0000) libpthread.so.0 => /opt/lib/libpthread.so.0 (0x2ac85000) libdl.so.0 => /opt/lib/libdl.so.0 (0x2acaa000) libm.so.0 => /opt/lib/libm.so.0 (0x2acbd000) ... Кроме того, для бинарников с установленными битами setuid или setgid содержимое LD_LIBRARY_PATH игнорируется по соображением безопасности. Это можно проверить, скажем, на пакете sudo. Если для сборки пакетов будет использовать билдут с этой правкой, то костыль с установкой LD_LIBRARY_PATH не понадобится.

1) Кажется, есть противоречение между wiki и прошивкой. Согласно этой статьи в среду должны передаётся: LD_LIBRARY_PATH=/opt/lib:/opt/usr/lib:/lib:/usr/lib Однако /lib/libndmOpkg.so при запуске initrc экспортирует в среду: LD_LIBRARY_PATH=/lib:/usr/lib:/opt/lib:/opt/usr/lib Это можно воспроизвести, написав «фальшивый» скрипт /opt/etc/init.d/S99fake со следующим содержимым: #!/bin/sh export > /opt/tmp/env.tst В итоге при запуске внешних сервисов возможны жалобы can't resolve symbol с аварийным завершением работы.

Как я пока что понимаю, несмотря на присутствие в base-files скриптов /lib/functions, OpenWrt'шный механизм не будет использоваться ни для конфигурирования пакетов, ни для запуска сервисов, т.к. для запуска выбрана NSLU-like схема /opt/etc/init.d/Sxx. Соответсвенно, Makefile'ы для половины пакетов всё равно придётся править, хотя бы ради добаваления скриптов запуска.

Насколько понимаю, сейчас среда NDM Systems Buildroot сделана так, чтобы как можно меньше отличаться от OpenWrt Buildroot. Пакеты конфигурируются, компилируются и пакуются без упоминания префикса /opt, что позволяет использовать Makefile'ы OpenWrt'шных пакетов без какой-либо модификации, а для распаковки на роутере в конфиге opkg.conf указывается опция dest root /opt. В частности, вижу в билдруте NDM: $ cat include/package-defaults.mk ... CONFIGURE_PREFIX:=/usr CONFIGURE_ARGS = \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --program-prefix="" \ --program-suffix="" \ --prefix=$(CONFIGURE_PREFIX) \ --exec-prefix=$(CONFIGURE_PREFIX) \ --bindir=$(CONFIGURE_PREFIX)/bin \ --sbindir=$(CONFIGURE_PREFIX)/sbin \ --libexecdir=$(CONFIGURE_PREFIX)/lib \ --sysconfdir=/etc \ --datadir=$(CONFIGURE_PREFIX)/share \ --localstatedir=/var \ --mandir=$(CONFIGURE_PREFIX)/man \ --infodir=$(CONFIGURE_PREFIX)/info \ $(DISABLE_NLS) \ $(DISABLE_LARGEFILE) \ $(DISABLE_IPV6) Получается, что пакеты, которые конфигурируются с помощью GNU Build System (половина, а то и большинство) получат в своих бинарниках hardcoded-пути: /etc для поиска своих конфигов, /var — для сохранения временных данных, /usr/share для поиска данных и т.п., что неправильно. Правильный вариант кроме указания корректных опций конфигурирования потребует соответсвующего изменения Makefile'ов пакетов, что значительно более трудоёмкая задача. Первый путь был выбран исходя из перечисленных доводов? Не будет ли это нарушение FHS выглядеть коряво? Здесь лежат все необходимые правки билдрута, если будет выбран «правильный» путь. С пакетами, повторюсь, придётся повозиться отдельно.

Совершенно верно, те же uclibc обновить или base-files к примеру...Тогда наиболее логичный путь — это установка первым делом полноценного opkg. И не надо будет обременять "эмулятор" opkg всеми функциями настоящего (в части, записью статусов распакованных пакетов в /opt/lib/opkg/status), и будет возможность обновлять в т.ч. базовые файлы и uclibc-библиотеки.

В смысле? Т.е. при выполнении opkg upgrade должны обновляться в т.ч. те пакеты, которые были распакованы из /opt/install?Про Entware пока речь не заходила, но там не в пакетах только сам статический бинарник opkg. Это сделано умышлено, для того, чтобы он остался работоспособен даже в том случае, если остальная система в руинах. Кстати, сто́ит ли мне сделать такой html-индекс для keenopt для облегчения навигации по пакетам? Чуть позже сделаю на своих мощностях, посмотрим насколько будет полезен.

Примеры из моих пакетов: раз, два, три. Раз у /opt/install цель — установить окружение для работы, то теоретически может понадобиться и /opt/bin/sh. Это можно учесть в зависимостях пакета, если, конечно, при установке из /opt/install эти зависимости будут учитываться. Если зависимости не будут учитываться, что хорошо бы распаковывать пакеты из /opt/install в алфавитном порядке, тогда зависимости можно будет соблюсти, назвав пакеты 00utility1.ipk, 02utility1.ipk и т.д.

Пока просто вожу руками в воздухе. Если удастся получить девайс на тест, то внесу посильный вклад. Первая засада с выполнением post/pre-inst скриптов видится в том, что они представляют собой shell-скрипты, начинающиеся shebang'ом #!/bin/sh и к моменту их выполнения /opt/bin/sh ещё может не существовать.

Правильно ли я понимаю то, что пакеты, положенные в папку /opt/install будут распаковываться при каждой загрузке роутера, причём post/pre-inst скрипты в пакетах выполняться не будут?

Скорее всего, в .config билдрута указана CONFIG_SOFT_FLOAT, а тулчейн собран с hardfloat.