Jump to content

OmegaTron

Forum Members
  • Posts

    228
  • Joined

  • Last visited

Posts posted by OmegaTron

  1. На 2.11.C.0.0-2 в netfilter.d были добавлены правила и с тех пор успешно работали. После обновления на 2.13.C.0.0-1 в логах наблюдаю такие строки

    ndm: Opkg::Manager: /opt/etc/ndm/netfilter.d/001iptables: exit code 1.
    ndm: Opkg::Manager: /opt/etc/ndm/netfilter.d/001iptables: iptables: Invalid argument. Run `dmesg' for more information.

    В шапке скрипта 001iptables добавлено

    [ "$type" == "iptables" ] && exit 0
    [ "$table" != "filter" ] && exit 0
    xxx
    xxx

    где xxx - правила. При запуске из баша скрипт отрабатывает нормально, правила что им, что вручную добавляются нормально.

    В чём затык ? dmesg посмотреть не успел. Сам скрипт, судя по добавленным при старте правилам вполне себе отрабатывает.

  2. И ... опять. В логах ничего криминального. Видно как по LAN'у цепляется соседний роутер, когда включается и как позднее падает линк и демон pppd начинает молотить по кругу

    Nov  3 10:15:39 ndm: Network::Interface::Switch: "FastEthernet0/3": switch link up at port 3.
    Nov  3 10:15:41 ndm: Network::Interface::Switch: "FastEthernet0/3": switch link down at port 3.
    Nov  3 10:15:43 ndm: Network::Interface::Switch: "FastEthernet0/3": switch link up at port 3.
    Nov  3 10:40:58 pppd[23881]: No response to 3 echo-requests
    Nov  3 10:40:58 pppd[23881]: Serial link appears to be disconnected.
    Nov  3 10:40:58 pppd[23881]: Connect time 2927.6 minutes.
    Nov  3 10:40:58 pppd[23881]: Sent 42325401 bytes, received 581548157 bytes.
    Nov  3 10:40:58 ndm: Network::Interface::IP: "PPPoE0": IP address cleared.
    Nov  3 10:40:58 ndm: Dns::Manager: name server 8.8.8.8, domain (default) deleted.
    Nov  3 10:40:58 ndm: Dns::Manager: name server 8.8.4.4, domain (default) deleted.
    Nov  3 10:40:59 ndm: Network::InternetChecker: Internet access lost.
    Nov  3 10:41:04 pppd[23881]: Connection terminated.
    Nov  3 10:41:04 pppd[23881]: write: Bad file descriptor (9)
    Nov  3 10:41:04 pppd[23881]: Sent PADT
    Nov  3 10:41:04 pppd[23881]: Modem hangup
    Nov  3 10:41:04 pppd[23881]: write: Bad file descriptor (9)
    Nov  3 10:41:04 pppd[23881]: Exit.

    Всё как обычно - по LAN'у оба роутера друг друга не видят, интернет и мультикаст валится у обоих (у Омни II отрублен igmp proxy во избежание коллизи, но врублен udpxy), доступ есть только по вафле. Причём в этот раз Омни отказался мне лог отдавать - загрузка файла входила в loop (строки выше взяты из syslog'a). После ребута Омни сеть очухивается и всё работает последние 2-е суток в штатном режиме. До поры, до времени ...

  3. Сейчас к слову помониторил - авторизация через веб-фейс фиксируется 100%, а вот к /ci как-то непонятно, через раз. Пока системы не понял ибо мониторил недолго.

    11 час назад, stefbarinov@mail.ru сказал:

    И ещё какая-то абра-кадабра отображается, скрин прилагаю.

    Это id сессии, которая была авторизована.

  4. В 29.10.2018 в 23:07, dvg_lab сказал:

    Версия ПО 2.13.C.0.0-3, и у меня все пашет, проверено на Ultra - II, где-то что-то все же не учитывается. Куку обязательно сохранять и пихать ее в ответном пакете, аккуратно со всеми \n, перепроверять хеши...

    Перед тем как сегодня отписаться, начал перепроверку кода под микроскопом (всмысле с отладкой) и таки была замечена пара просчётов - md5sum выполнялся без обрезки мусора после выхлопа, а printf в realm из-за пробелов выдавал только первый блок. Разбираться с экранированием буду позже (ибо с printf манипуляций меньше), пока вернулся назад к echo и обрезке \n через tr -d "\n". Теперь наконец всё работает и ответ от роутера "HTTP/1.1 200 OK" ))) C куками к слову всё было в порядке, просто глаз замылился и я в упор не видел ошибку :(

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

    Значит никаких проблем с авторизацией в 2.13 нету.

    Не факт. eralde писал об аналогичных проблемах, что и у меня. У вас какой билд ? У меня юзается экспериментальная сборка 2.13.C.0.0-1

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

    Мои предположения почему у тебя не получается: когда ты генеришь на баше json, ты это делаешь с первоначальной кукой (токеном), которую ты получил тем же curl'ом, а когда запускаешь curl второй раз, с уже якобы готовым json'ом, то у тебя по факту уже новая сессия и новая кука (токен), а нужно чтобы сессия не разрывалась и пихалась в ответ та кука которая пришла в этой сессии.

    Нет с куками я тоже пробовал.

    В 18.10.2018 в 09:56, OmegaTron сказал:

    upd: При дополнительной отправке куки сессии полученной в первоначальном get-запросе html-выхлопа не происходит, только в ответных хедерах вылезает 401-я ошибка.

    Единственный момент, который я не учёл - это было использование echo при генерации хэша, который давал \n на конце и делал кэш не валидным. К сожалению, его замена на printf не привела к желаемому результату - роутер всё равно шлёт меня лесом при авторизации, в том числе с куками (специально сегодня перепроверял разные варианты авторизации после замены echo на printf). Как буду дома - скину скрипт для проверки :)

  6. В 26.10.2018 в 16:23, dvg_lab сказал:

    Я все это делал на перле, curl не умеет в новую авторизацию.  Не знаю каким образом он может собрать это:

    curl не может, но на баше через md5sum и sha256sum можно сгенерировать всё необходимое и потом всё это отправить curl'ом json как data в post запросе. Если интересует, могу скинуть свой скрипт.

    Только на 2.13 от него нет проку. Там для авторизации требуется что-то ещё.

  7. Проблема снова вылезла, но уже на 2.13.C.0.0-1. На всех устройствах отвалился интернет и мультикаст. Снова с одного роутера нельзя было достучаться по lan до другого. Перезагрузил Омни, подключившись по вафле, после чего вся сеть очухалась.

    Как с этим бороться ?

  8. 1 час назад, Le ecureuil сказал:

    Авторизация через digest закончилась, больше не поддерживается в связи с переходом нового Web на form-based.

    Да бог с digest-авторизацией. Я могу использовать и новую, если подскажете как. Я в соседней теме бился, но каменный цветок увы не вышел. А что я там делал не так, мне так и не сказали, хотя указанный алгоритм я соблюдал.

    1 час назад, Le ecureuil сказал:

    Если нужно, то сделайте проброс на 127.0.0.1:79, там будет вообще без авторизации.

    Видел в перекрёстной теме, пока думаю, но хотелось бы добить вариант с авторизацией. Скрипт готов, но авторизация всё равно не проходит т.к. вероятно для авторизации не хватает каких-то нюансов, о которых не упомянули в соседней теме.

  9. Может я что-то упустил, но вроде раньше при авторизации через браузер или при обращении к ci я видел в логах строки об проведённой аутентификации. Теперь там тишина :(

    Хотя возможно я путаю - у меня параллельно стоит оригинальный Keenetic, который при авторизации сразу отсылает в syslog и по сети уведомление об авторизации. Так что возможно, мне просто показалось, что Омни так же делал. Ежели показалось, то не лишним было бы подобное запилить.

    Сессия длительностью в 10 минут, новая схема авторизации, а банального учёта логинился ли кто - нет.

    • Thanks 1
  10. В 16.10.2018 в 20:33, eralde сказал:

    Авторизация теперь работает так:

    Так, то ли лыжи не едут, то ли я

    Цитата

    X-NDM-Challenge: ZGENTERUUDCKTARJNNYYNLFLSSCITQVO
    X-NDM-Realm: ZyXEL Keenetic Omni II

    Данные без хэширования

    ZGENTERUUDCKTARJNNYYNLFLSSCITQVOadmin:ZyXEL Keenetic Omni II:aaabbbccc123

    X-NDM-Challenge + хэш второго блока в md5

    ZGENTERUUDCKTARJNNYYNLFLSSCITQVO5da4a889c4a614daff93dcd11c0734e4

    и наконец всё это добро в sha256

    672b1977d3daed6538c0fb73cf597b384f4cd96814578ca1dc0d3aa26b982bf9

    Отправляю

    curl -sv "http://192.168.1.15:10080/auth" -X POST -H "Content-Type: application/json" --data-binary '{"login":"admin","password":"672b1977d3daed6538c0fb73cf597b384f4cd96814578ca1dc0d3aa26b982bf9"}'

    получаю в отладке

    < HTTP/1.1 400 Bad Request
    HTTP/1.1 400 Bad Request
    

    и аналогичный html-выхлоп

    <html>
    <head>
    </head>
    <body>
    <h1>400: Bad Request</h1>
    </body>
    </html>

    Ну и где я ошибся ?

    p.s. Оригинальный пароль другой и все манипуляции проводились именно с ним, а "aaabbbccc123" - просто пример, с которым я провёл те же манипуляции. С оригинальным паролем была именно 400-я ошибка - Bad Request. Все манипуляции выполнялись под никсами, дабы исключить какие-либо проблемы с кросскомпилированными бинарниками.

     

    upd: При дополнительной отправке куки сессии полученной в первоначальном get-запросе html-выхлопа не происходит, только в ответных хедерах вылезает 401-я ошибка.

  11. 2 часа назад, eralde сказал:

    http://cmder.net/ -- выглядит как хорошая штука, на мой взгляд.

    По иронии, буквально на днях познакомился с данной сборкой. Согласен, вещь хорошая - синтез conemu и clink. Т.к. функционала последнего уже перестало хватать, пришлось искать альтернативу.

    Добавьте кнопку "Выйти" в веб-интерфейсе.

    Понятно. Хотели как лучше, а получилось как всегда )))

    где  есть wget/curl и всякие другие штуки, не могу вспомнить где и что брал.

    С этим проблем нет. Я беру бинарники либо из набора unxtools, либо использую cygwin'овский загрузчик под win для загрузки чего-то специфического.

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

    Раньше была digest-авторизация. Теперь -- не digest

    Понятно. Просто обычно я имел дело с basic-авторизацией, а если попадался digest, то все проблемы решались дополнительным ключём для curl'a и в дебри отладки не лез, если только не попадалось что типа такого :D После того как полез увидел по заголовкам нечто напоминающее digest и "завис" ...

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

    А для тех, кто знает слова digest и curl -- вроде несложно.

    Не то чтобы сложно, просто это дополнительный гемморой, который неясно по какой причине появился и который предстоит решать.

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

    На вопросы по ndmq я ответить не могу. Что вы хотите сделать? Какой-то скрипт для пакетного применения настроек?

    Скрипт, но не применения настроек, а для получения и обработки определённых данных с роутера :)

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

    Можно написать на любом скриптовом языке. В Windows 10 вроде даже нормальный терминал завезли.

    10-ку я не перевариваю, уж не обессудьте ? максимум 7-ка

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

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

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

    ***

    К слову, с my.keenetic.net каменный цветок так и не вышел

    Цитата

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

    <html>
    <head><title>401 Authorization Required</title></head>
    <body bgcolor="white">
    <center><h1>401 Authorization Required</h1></center>
    <hr><center>Web server</center>
    </body>
    </html>

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

    <html>
    <head><title>401 Authorization Required</title></head>
    <body bgcolor="white">
    <center><h1>401 Authorization Required</h1></center>
    <hr><center>Web server</center>
    </body>
    </html>

     

    так что займусь велосипедом ...

  13. Авторизация теперь работает так:

    ОК ! Спасибо :)

    Буду эксперементировать. Я упустил realm + не знал, алгоритм генерации хэша (думаю, это простительно, если учитывать тот момент, что с прямой digest-авторизацией я до этого не имел дела).

    Я так понимаю, все эти меры безопасности связаны с тем, что идентичный метод авторизации использует приложение для смартфонов ? Иначе я просто не понимаю, к чему такие сложности на домашнем роутере )))

    Судя по количеству манипуляций, под windows получится явно громоздкая конструкция, а это целевая система :| Никсы на подхвате на vbox. Функционал для работы с rci будет включён в ndmq ?

    Ну и раз уж пошёл разговор про ndmq, существуют ли готовые сборки для cygwin под win (сам я профан в кросс-компиляции) ?

    Но, если судить по тому, что новый интерфейс вам не нравится -- имеет смысл переключиться на legacy (2.11.D)
    Если 2.13 будет стабильная как танк и выдержит аптайм в месяц - два, буду пользоваться ею :) Последняя 2.11, которой я пользовался (2.11.C.0.0-2), падала раз в пару дней. Судя по ченджлогу, с того момента многое исправили, но пока проверять стабильность не хочется. Если фейс и ещё какие-то моменты окончательно задолбают - перейду на 2.11.D
  14. 24 минуты назад, eralde сказал:

    ОК. Спасибо. Проверять вариант с my.keenetic.net буду завтра, как роутер будет в зоне доступа. Теперь ясно когда всё поломалось.

    Цитата

    Подсмотреть как именно происходит авторизация можно в коносоли разработчика браузера. Либо напишите мне в личку.

    Я смотрел кстати, только толку от этого было ноль, ибо слишком хитро  всё теперь сделано. Там идёт post-запрос с отправкой json'a с логином и паролем в виде 64-х значного криптованного хэша (или типа того), который при каждой новой авторизации перегенеривается, после чего отдаётся кука сессии и браузер получает-принимает запросы. Вот только воспроизвести это curl'ом не получается. Вместо "хэша" (?) я пробовал совать реальный пароль, но на выходе получал не то bad request (400), не то 401 без html, в ответных хедерах. Думается мне, что нужна отправка именно "хэша", вот только я не в курсе алгоритма его генерации.

  15. 37 минут назад, AndreBA сказал:

    Переходите на 2.11 [legacy]. Там вроде сохранен старый интерфейс. В общем почитайте и подумайте.

    Понятно. Просто дошли руки обновиться с 2.11.C.0.0-2, которая постоянно падала на последнюю draft-прошивку (которая оказалась на редкость стабильна) с которой за компанию прилетел данный "бонус" в виде непривычной новой веб-морды и некоторого дополнительного геммороя с ней связанного ( речь об /rci/ ).

  16. О проблеме я уже отписывался в соседней теме, но там этот вопрос проигнорировали. При запросе rci с digest-авторизацией на 2.13.C.0.0-1 веб-сервер роутера шлёт лесом

    curl -s --digest --user  xxx:xxx "http://192.168.1.15:10080/rci/show/interface?name=PPPoE0" -H "Content-Type: application/json"
    
    <html>
    <head><title>401 Authorization Required</title></head>
    <body bgcolor="white">
    <center><h1>401 Authorization Required</h1></center>
    <hr><center>Web server</center>
    </body>
    </html>

    при отправке запроса к ci (xml) всё отрабатывает, при отправке запроса к rci с кукой сессии из браузера - всё работает. На ранее юзаемой 2.11.C.0.0-2 с rci проблем не было.

     

  17. vasek00, я в курсе про ndmq и xmlstarlet, но xml мне просто не нравится. json через jq в разы удобнее распарсивать и с json-api тупо удобнее работать. И относительно "навороченного" я спрашивал именно про него.

  18. Мануал до сих пор в процессе ? После обновления с 2.11 до 2.13 всё, что работало для 2.11 поломалось. Теперь опять надо лезть в отладку браузера и изучать всё под микроскопом. Хочется этого избежать и почитать нормальные доки.

    curl -s --digest --user  xxx:xxx "http://192.168.1.15:10080/rci/show/interface?name=PPPoE0" -H "Content-Type: application/json"
    
    <html>
    <head><title>401 Authorization Required</title></head>
    <body bgcolor="white">
    <center><h1>401 Authorization Required</h1></center>
    <hr><center>Web server</center>
    </body>
    </html>

    С XML'ем и тем же digest'ом всё вполне шуршит, но xml юзать не комильфо. Чего там опять наворотили ?

  19. Примечательно, но с того момента, как я переправил свой костыль для обхода дубликации правил iptables в виде дубликата исходного правила с ключём "-D", поставленного в начало скрипта, на проверку условий, как это предложено на гитхабе (лень было до этого с этим вопросом разбираться), роутер имеет вот уже недельный аптайм. До этого работа без самовольного ребута по неясным (для меня) причинам длилась от силы пару суток. Возможно это просто совпадение, но всё же.

×
×
  • Create New...