Jump to content

OmegaTron

Forum Members
  • Posts

    228
  • Joined

  • Last visited

Posts posted by OmegaTron

  1. 1 час назад, ndm сказал:

    @OmegaTron: ситуация должна заметно улучшиться в версии 2.12.A.3.0-4.

    Вы расскажите, в чём цимес ситуации и почему роутер тогда повисал.

    Касательно установки 2.12 - я хз, мне в соседней ветке писали что прошивки из этого "эшелона" чересчур тяжёлые.

  2. 1 минуту назад, sergeyk сказал:

    Проще всего, пожалуй, через браузер

    В том случае

    1 минуту назад, sergeyk сказал:

    доступ лишь через ssh, а всё остальное отвалилось.

    В данном случае, веб-морда не отвечала и через минуту отваливалась

    2018-02-11 15:33:51    Daemon.Error    192.168.0.1    Feb 11 15:32:50 keenetic_omni nginx: (conn: *1406) upstream timed out (145: Unknown error) while reading response header from upstream, client: 192.168.0.245
    2018-02-11 15:33:51    Daemon.Error    192.168.0.1    Feb 11 15:32:50 keenetic_omni nginx: (conn: *1400) upstream timed out (145: Unknown error) while reading response header from upstream, client: 192.168.0.245

    Так что не проще. Если по этим запросам

    3 минуты назад, sergeyk сказал:

    http://192.168.1.1/rci/show/threads

    http://192.168.1.1/rci/more?filename=log

    отдаются txt, как в случае с */ci/* то можно попробовать в следующий раз слить через curl/wget,  хотя я лучше поступлю более радикально https://forum.keenetic.net/topic/527-запись-syslog-на-внешний-usb-диск-с-помощю-syslog-ng/

  3. 3 часа назад, sergeyk сказал:

    В момент вывода сообщений.

    ОК. Главное, чтобы хоть что-то при этом отвечало - telnet/ssh/web. В данном случае работал web, да и то только через запросы к CI/RCI через curl/wget.

    Раз пошла такая пьянка - как через ssh имея доступ к корню дёрнуть упомянутые данные ? А то не так давно был сбой при котором был доступ лишь через ssh, а всё остальное отвалилось.

  4. 3 минуты назад, sergeyk сказал:

    Нужен был self-test или вывод "show threads" + log.

    На момент висяка или на текущий момент ? Если первое, то врятли это было бы возможно ибо веб-морда зависала, а прямых линков файлов я на тот момент не знал. ОК, буду иметь ввиду, что смотреть.

  5. 55 минут назад, Le ecureuil сказал:

    Нужен весь вывод syslog, в том числе и то, что случилось 25 тысяч секунд до этого куска.

    Комп до этого был выключен - эти цикличные блоки данных всё, что насыпалось в syslog. Адреса log.txt я на тот момент не знал (сейчас уже поглядел), а через CI/RCI дёрнуть лог не сообразил. Хотя я сомневаюсь, что он вообще бы отдался при такой клинике - там get/post запросы проходили с минутными задержками.

    55 минут назад, Le ecureuil сказал:

    А версия  прошивки-то хоть какая?

    Дык в подписи - 2.10.C.2.0-4

    Ещё момент - в entware кроме базового dropbear'a никакого софта нет, равно как и скриптов в автозагрузке. Руки до этого не дошли.

    На момент возникновения проблемы роутер никто не эксплуатировал и о висяке я узнал лишь постфактум.

  6. Сел сегодня за комп и обнаружил, что в syslog многовато данных с роутера валится. Посмотрел, в syslog циклично валилось следующее

    2018-02-11 15:11:08    User.Warning    192.168.0.1    Feb 11 15:10:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 24780 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:11:08    User.Warning    192.168.0.1    Feb 11 15:10:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 24775 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:11:08    User.Warning    192.168.0.1    Feb 11 15:10:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 24774 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:11:08    User.Warning    192.168.0.1    Feb 11 15:10:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8226 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:12:07    User.Warning    192.168.0.1    Feb 11 15:11:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 24840 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:12:07    User.Warning    192.168.0.1    Feb 11 15:11:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 24835 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:12:07    User.Warning    192.168.0.1    Feb 11 15:11:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 24834 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:12:08    User.Warning    192.168.0.1    Feb 11 15:11:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8286 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:13:07    User.Warning    192.168.0.1    Feb 11 15:12:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 24900 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:13:07    User.Warning    192.168.0.1    Feb 11 15:12:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 24895 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:13:07    User.Warning    192.168.0.1    Feb 11 15:12:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 24894 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:13:08    User.Warning    192.168.0.1    Feb 11 15:12:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8346 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:14:07    User.Warning    192.168.0.1    Feb 11 15:13:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 24960 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:14:07    User.Warning    192.168.0.1    Feb 11 15:13:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 24955 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:14:07    User.Warning    192.168.0.1    Feb 11 15:13:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 24954 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:14:08    User.Warning    192.168.0.1    Feb 11 15:13:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8406 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:15:06    User.Warning    192.168.0.1    Feb 11 15:14:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 25020 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:15:07    User.Warning    192.168.0.1    Feb 11 15:14:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 25015 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:15:07    User.Warning    192.168.0.1    Feb 11 15:14:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 25014 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:15:08    User.Warning    192.168.0.1    Feb 11 15:14:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8466 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:16:06    User.Warning    192.168.0.1    Feb 11 15:15:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 25080 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:16:06    User.Warning    192.168.0.1    Feb 11 15:15:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 25075 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:16:07    User.Warning    192.168.0.1    Feb 11 15:15:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 25074 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:16:07    User.Warning    192.168.0.1    Feb 11 15:15:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8526 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:17:07    User.Warning    192.168.0.1    Feb 11 15:16:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 25140 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:17:07    User.Warning    192.168.0.1    Feb 11 15:16:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 25135 seconds acquired Feb 11 08:17:10.
    2018-02-11 15:17:07    User.Warning    192.168.0.1    Feb 11 15:16:06 ndm: Core::Watchdog: Interface Bridge0 neighbour explorer holds ARP_TABLE (57) lock 25134 seconds acquired Feb 11 08:17:11.
    2018-02-11 15:17:08    User.Warning    192.168.0.1    Feb 11 15:16:06 ndm: Core::Watchdog: Event sender holds CORE (2) lock 8586 seconds acquired Feb 11 12:52:59.
    2018-02-11 15:18:06    User.Warning    192.168.0.1    Feb 11 15:17:05 ndm: Core::Watchdog: Statistics collector thread holds ULTIMATE (255) lock 25200 seconds acquired Feb 11 08:17:05.
    2018-02-11 15:18:06    User.Warning    192.168.0.1    Feb 11 15:17:05 ndm: Core::Watchdog: Timer holds CORE (2) lock 25195 seconds acquired Feb 11 08:17:10.

     

    Увидев строки "core" и "Watchdog" подумал, что роутер основательно залип - так и оказалось. Telnet не отвечал, ssh из комплекта entware не отвечал (соединение вроде устанавливалось, но залипало и висело), коннекта к интернету не было. Единственное, что хоть что-то отвечало - это веб-фейс. После авторизации он отображался, но на динамически обновляемых блоках висел прогресс-бар, который крутился бесконечно. Спустя пару минут в веб-фейсе появлялись ошибки "error: not responded" (или типа того) и восклицательный знак в углу, а в syslog валилось

    2018-02-11 15:33:51    Daemon.Error    192.168.0.1    Feb 11 15:32:50 keenetic_omni nginx: (conn: *1406) upstream timed out (145: Unknown error) while reading response header from upstream, client: 192.168.0.245
    2018-02-11 15:33:51    Daemon.Error    192.168.0.1    Feb 11 15:32:50 keenetic_omni nginx: (conn: *1400) upstream timed out (145: Unknown error) while reading response header from upstream, client: 192.168.0.245

    Попытался ребутнуть роутер через CI, получил ответ

    <packet>
        <response id="0">
            <message>rebooting the system</message>
        </response>
    </packet>

    но ребута не случилось (выждал минут 5) и роутер пришлось дёргать по питанию. После включения сообразил, что можно было дёрнуть через CI лог, но было уже поздно :( Сегодня займусь установкой syslog-ng (или как его там), надоели уже такие случаи.

     

    Теперь вопрос - что это могло быть ?

  7. Ещё момент - некоторые компоненты, насколько я понимаю, вполне заменимы софтом из entware (это к теме "лишних" запчастей) и компонент "Общий доступ к файлам и принтерам (SMB/CIFS)" можно спокойно заменить samb'ой, а "Захват сетевых пакетов" tcpdump'ом (если они дефакто вообще не одно и то же) ?

  8. 7 часов назад, Le ecureuil сказал:

    После этого вопросы по идее должны отпасть.

    Отпали. Просто я мобильными модемами не пользуюсь - юзаю стационарный вариант, ввиду чего всё связанное с usb-модема отрубил (а модуль получается остался).

    19 часов назад, Le ecureuil сказал:

    nfs и cifs вы сами поставили в виде компонента ndm-mod-opkg-kmod-fs. Если он вам не нужен, то смело отключайте - для NDMS это не нужно, только для Entware.

    Эм, понятно. Просто я думал что-то это что-то связанное с fuse, поэтому поставил до кучи, а оно вон как. Ну да ладно пусть стоит.

  9. 10 часов назад, abychkov сказал:

    Да любой роутер с usb разъемом  или без  usb и  OpenWRT , собирайте любые прошивки под свои потребности

    Ключёвое слово собирайте, а вопрос был, какой ещё производитель делает роутеры с аналогичным конфигураторатором компонентов стоковой прошивки и её загрузчиком, который позволяет буквально за пару кликов получить готовую прошивку.  Вот я например не могу вспомнить. Такое ноу-хау лишь у zyxel'ей.

    #

    Что-то заданный ранее вопрос совсем убежал вверх

    11 час назад, OmegaTron сказал:

    Вы меня не поняли. Я не имею ввиду скачивание прошивки с выбранным набором компонентов РОУТЕРОМ, я имею ввиду скачивание прошивки вручную, на компьютере, через GET или POST запрос. Ведь механизм существует. Вопрос в том открыто ли API или закрыто и имеется ли реализация его использования (aka веб-форма).

    Так есть у кого информация по данному вопросу или сие коммерческая тайна ? Меня бы устроили равно как веб-форма, так и программа-загрузчик. Если таковых не существует сгодится и пример запроса прошивки через wget/curl. Просто нужна возможность сливать прошивку не задействуя роутер. Как уже писал ShadoW

    10 часов назад, ShadoW сказал:

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

    т.к.

    10 часов назад, OmegaTron сказал:

    В связи с недавними событиями (отписывался в одной из недавних тем) "насиловать" флеш дополнительными перепрошивками крайне нежелательно

     

  10. 5 минут назад, AndreBA сказал:

    За то время сколько существует stable или delta можно на свой вкус и цвет собрать кучу прошивок с разной комбинацией компонентов. Все эти прошивки хранить у себя на РС и прошиваться хоть каждый день.

    В связи с недавними событиями (отписывался в одной из недавних тем) "насиловать" флеш дополнительными перепрошивками крайне нежелательно, а то не ровен час подохнет :( 

  11. 29 минут назад, Mamay сказал:

    Вам же ответили выше очень подробно о системе распространения версий. Пока в канале висит определённая версия, например 2.10, нужно успеть собрать под свой вкус сборку компонентов. После смены версии на канале, опять же например на 2.11, поезд обосносновано считается ушедшим, со всеми вытекающими... 

    Вы меня не поняли. Я не имею ввиду скачивание прошивки с выбранным набором компонентов РОУТЕРОМ, я имею ввиду скачивание прошивки вручную, на компьютере, через GET или POST запрос. Ведь механизм существует. Вопрос в том открыто ли API или закрыто и имеется ли реализация его использования (aka веб-форма).

  12. 2 минуты назад, Le ecureuil сказал:

    Когда ее заменят на 2.11, то уже никак.

    Версия лежит в определенном слоте, называемом stable / beta / delta / draft. Если в этот слот выложили другую версию, то она и соберется. Запросить предыдущую версию невозможно.

    Не, я о другом. Я имел ввиду, как запросить текущий билд stable / beta / delta / draft с определённым набором компонентов в виде файла прошивки. Может на сайте zyxel'ей есть веб-форма какая (о которой я не знаю), которая позволит сгенерировать и загрузить готовый файл прошивки ? Или всё хранится в потрохах роутера за семью печатями ?

  13. 1 час назад, Mamay сказал:

    2.10 практически всё. Актуальны нынче 2.11 и пока находящаяся в стадии разработки 2.12...

    Понятно :| Когда 2.10 закончится "совсем", хотя-бы ориентировочно ?

    57 минут назад, r13 сказал:

    Она занимает больше места

    Ясно.

    1 час назад, Mamay сказал:

    P.S. Чтобы иметь нужный вам набор компонентов в любой версии, необходимо посредством webui слить локально прошивку и хранить оную аки зеницу ока...

    А иных вариантов получить прошивку с определённым набором кроме повторной перепрошивки нет ? Ведь запрашивает же роутер на сервере набор компонентов и тот собирает прошивку, которую он (роутер) загружает и ставит. Или информация по данному механизму закрытая ?

  14. 26 минут назад, r13 сказал:

    Главное нарежте себе прошивок с нужными компонентами в закрома, а то скоро в этом канале уже 2.11 будет.

    А как ? Путём слива блока верез cat или запросом к серверу, где генерятся прошивки ? Если второе, то я даже не занимался этим вопросом (ткните если обсуждалось) :| Если первое, укажите, какие блоки дампить.

    upd: Вспомнил, там же прошивку можно через веб-фейс в разделе "файлы" слить

    p.s. А что не так с 2.11 относительно 2.10 ?

  15. 3 часа назад, r13 сказал:

    После смены канала обновлений удалять/ добавлять компоненты можете через веб как обычно. 

    Я так и сделал поначалу - зашёл в веб-фейс и проверил список элементов, только затребованных элементов не было. После попытки установки через cli они появились со статусом "будет установлен". Попробую запустить апдейт оттуда.

  16. В 02.02.2018 в 00:39, Le ecureuil сказал:

    Понимаете, тут нет людей на зарплате, которые должны вам отвечать. Все чисто на энтузиазме каждого.

    Я всё понимаю, но можно было просто ткнуть в эту тему https://forum.keenetic.net/announcement/5-где-взять-тестовые-прошивки/ и все вопросы сразу бы отпали :) Там разжёвано что есть draft, что есть delta (о чём я и интересовался).

    В 02.02.2018 в 00:39, Le ecureuil сказал:

    Поэтому если не хотите думать - купите новый роутер с поддерживаемой прошивкой 2.09 (или выше), и обращайтесь в техподдержку - они вам все подробно расскажут, ведь вы за это заплатили.

    Да я не против подумать ))) Просто если есть возможность решить вопрос быстро, я стараюсь это сделать, нет - иду "долгим" путём.

    ***

    Итак, вернулся я к данному вопросу, вбил в cli

    components list delta
    	components commit

    увидел, что пошло обновление (до этого никогда данной командой не пользовался), дождался, пока пройдёт апдейт (прошивка теперь 2.10.C.2.0-4), заглянул в мануал, потом снова в cli и набрал команды

    components list delta
    components remove fat
    components install opkg-kmod-netfilter
    components install opkg-kmod-netfilter-addons
    components commit

    только вот вместо

    FileSystem::Repository: Firmware update started.

    что было в прошлый раз, в консоли вылезло

    Components::Manager error[24249130]: request failed (404).

    WTF ? В списке запрашиваемые и удаляемые компоненты были :/

  17. После того как был отключён ворох "рекомендованных" компонентов, роутер стал работать в разы стабильнее и перестал по непонятным причинам ребутиться и стал работать сутками напролёт. Ввиду этого началась паранойя на тему "лишних запчастей".

    Намедни, в логе глаз зацепился за следующие модули

    /lib/modules/3.4.113/cdrom.ko.
    /lib/modules/3.4.113/cifs.ko.
    /lib/modules/3.4.113/nfs.ko.
    /lib/modules/3.4.113/nfsd.ko.
    /lib/modules/3.4.113/fastvpn.ko

    Можете растолковать, для чего они (мало ли, вдруг не для того, о чём я думаю).  Если я верно понял, cdrom.ko - для подключения привода к ... кхм ... роутеру, cifs - для монтирования smb-шар (или это модуль компонегта cifs, отвечающего за smb-шару на роутере ?), nfs.ko - монтирование nfs - шар, nfsd.ko (для поднятия nfs-сервера ?), fastvpn.ko - не понял для чего он ибо никаких vpn-ов в помине нет.

  18. 22 часа назад, Le ecureuil сказал:

    Это конфигурационные. Для управления нужно слать команды через метод POST.

    Разобрался. Там общение json'ами идёт и в обратную сторону. Методом тыка и на основе анализа полной команды остановки/запуска интерфейса через POST с озвученными мной выше командами был отправлен json

    {"123":false}

    что привело к инициализации команд. Что там должно быть на месте "123" я хз, но пробел и пустая строка игнорируются, а всё остальное - принимается.

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

    p.s. Таки я походу при анализе не туда смотрел, управление в веб-фейсе как раз через RCI идёт, а CI - вторичен.

    Думаю, с дальнейшими экспериментами до появления мануала можно завязать.

    upd: Всё-таки соврал - в первом curl'е ис json'ами проблема. Походу в том релизе проблемы с digest-запросами в принципе.

  19. 10 часов назад, Le ecureuil сказал:

    Лучше дождаться мануала, там будет подробно рассказано, как формировать JSON для RCI.

    Да мне то всего-то и нужны команды остановки и подъёма интерфейса. Команду я составил по идее правильно, но она не работает, как задумано

    curl -s --digest --user  xxx:xxx 'http://192.168.1.1:10080/rci/interface/down?name=PPPoE0' -H 'Content-Type: application/json'

    на выходе

    {
    	}

    без какой либо реакции роутера. Подаю команду подъёма

    curl -s --digest --user  xxx:xxx 'http://192.168.1.1:10080/rci/interface/up?name=PPPoE0' -H 'Content-Type: application/json'

    на выходе получаю

    true

    если опустить интерфейс вручную, то вместо "true" появляется

    {
    	}

    и я не могу понять, управляющие это запросы или информационные. Если первое, то чяднт ? Если второе - каков "правильный" запрос ? Насколько я понял, веб-фейс через RCI только снимает данные, а управляющие запросы шлёт через CI xml-ки через POST, поэтому проследить "управление" через RCI у меня подручными средствами не получится.

  20. В 01.02.2018 в 17:43, Le ecureuil сказал:

    Спасибо :) Пригодится для скриптов.

    В 01.02.2018 в 17:43, Le ecureuil сказал:

    А во-вторых: http://files.keenopt.ru/cli_manual/Keenetic_Ultra_II/2018-01-23/cli_manual_ku_rd.pdf , раздел 4 - HTTP Core Interface.

    Ну на базе этого мануала я и строил команду(ы) по работе с API :)

    Единственное что не понятно, так это поведение curl'a. Или это зависит от того, насколько криво кодер собрал этот самый curl ?

    В 01.02.2018 в 17:43, Le ecureuil сказал:

    Новый CLI Guide с описанием RESTful Control Interface сейчас разрабатывается, и скоро тоже появится.

    ОК, буду ждать. А где посмотреть старый ? Или тот мануал по xml api он и есть ? Единственное, что пока не понял, как взаимодействовать с интерфейсами - посылаю запрос up + имя интерфейса, получаю "true", посылаю "down", получаю пустой выхлоп "{}". Зато информационные запросы "show" отдаются на ура.

    Через xml api с вкл/откл интерфейсов проблем нет.

  21. 9 минут назад, Mamay сказал:

    Вы вступили в ненужную ни кому, кроме вас, полемику. Все ваши ответы лежат на поверхности. И это не просто, а очень просто 2.102.112.12...

    Спасибо, буду изучать ;) Суть в том что когда голова забита пачкой вопросов, которые нужно решить, даже то, что лежит на поверхности проходит мимо меня :/ Потому я и прошу помощи.

  22. Ну и раз пошла такая пьянка - почему нигде не упоминается работа с API через json ? В дампах заметил отдаваемые веб-фейсом json'ы, поглядел отладку и получил следующий запрос

    curl -s --digest --user  xxx:xxx "http://192.168.1.1:10080/rci/show/interface?name=PPPoE0" -H "Content-Type: application/json"

    который отдаёт ту же информацию через GET. Только json в отличии от xml в разы проще парсить

×
×
  • Create New...