Jump to content

OmegaTron

Forum Members
  • Content Count

    116
  • Joined

  • Last visited

Community Reputation

5 Neutral

About OmegaTron

  • Rank
    Advanced Member

Equipment

  • Keenetic
    Omni II [v2.13.C.0.0-1]

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. OmegaTron

    Так, то ли лыжи не едут, то ли я Данные без хэширования 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-я ошибка.
  2. OmegaTron

    По иронии, буквально на днях познакомился с данной сборкой. Согласен, вещь хорошая - синтез conemu и clink. Т.к. функционала последнего уже перестало хватать, пришлось искать альтернативу. Понятно. Хотели как лучше, а получилось как всегда ))) С этим проблем нет. Я беру бинарники либо из набора unxtools, либо использую cygwin'овский загрузчик под win для загрузки чего-то специфического.
  3. OmegaTron

    Понятно. Просто обычно я имел дело с basic-авторизацией, а если попадался digest, то все проблемы решались дополнительным ключём для curl'a и в дебри отладки не лез, если только не попадалось что типа такого После того как полез увидел по заголовкам нечто напоминающее digest и "завис" ... Не то чтобы сложно, просто это дополнительный гемморой, который неясно по какой причине появился и который предстоит решать. Скрипт, но не применения настроек, а для получения и обработки определённых данных с роутера 10-ку я не перевариваю, уж не обессудьте ? максимум 7-ка Высчитать хэш не проблема. Просто придётся изобретать дополнительный велосипед для того, что и так уже ранее работало. *** К слову, с my.keenetic.net каменный цветок так и не вышел так что займусь велосипедом ...
  4. OmegaTron

    ОК ! Спасибо Буду эксперементировать. Я упустил realm + не знал, алгоритм генерации хэша (думаю, это простительно, если учитывать тот момент, что с прямой digest-авторизацией я до этого не имел дела). Я так понимаю, все эти меры безопасности связаны с тем, что идентичный метод авторизации использует приложение для смартфонов ? Иначе я просто не понимаю, к чему такие сложности на домашнем роутере ))) Судя по количеству манипуляций, под windows получится явно громоздкая конструкция, а это целевая система Никсы на подхвате на vbox. Функционал для работы с rci будет включён в ndmq ? Ну и раз уж пошёл разговор про ndmq, существуют ли готовые сборки для cygwin под win (сам я профан в кросс-компиляции) ? Если 2.13 будет стабильная как танк и выдержит аптайм в месяц - два, буду пользоваться ею Последняя 2.11, которой я пользовался (2.11.C.0.0-2), падала раз в пару дней. Судя по ченджлогу, с того момента многое исправили, но пока проверять стабильность не хочется. Если фейс и ещё какие-то моменты окончательно задолбают - перейду на 2.11.D
  5. OmegaTron

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

    Понятно. Просто дошли руки обновиться с 2.11.C.0.0-2, которая постоянно падала на последнюю draft-прошивку (которая оказалась на редкость стабильна) с которой за компанию прилетел данный "бонус" в виде непривычной новой веб-морды и некоторого дополнительного геммороя с ней связанного ( речь об /rci/ ).
  7. Только я успел привыкнуть к новой веб-морде и её в очередной раз поменяли. Есть возможность мигрировать на старую веб-морду ? Не нравится мне этот интерфейс а-ля smart-app.
  8. О проблеме я уже отписывался в соседней теме, но там этот вопрос проигнорировали. При запросе 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 проблем не было.
  9. vasek00, я в курсе про ndmq и xmlstarlet, но xml мне просто не нравится. json через jq в разы удобнее распарсивать и с json-api тупо удобнее работать. И относительно "навороченного" я спрашивал именно про него.
  10. Мануал до сих пор в процессе ? После обновления с 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 юзать не комильфо. Чего там опять наворотили ?
  11. Примечательно, но с того момента, как я переправил свой костыль для обхода дубликации правил iptables в виде дубликата исходного правила с ключём "-D", поставленного в начало скрипта, на проверку условий, как это предложено на гитхабе (лень было до этого с этим вопросом разбираться), роутер имеет вот уже недельный аптайм. До этого работа без самовольного ребута по неясным (для меня) причинам длилась от силы пару суток. Возможно это просто совпадение, но всё же.
  12. Так проблемы пофиксили или нет ?
  13. Так что там с мануалом ? Когда ждать или где искать ?
  14. В очередной раз сев за комп обнаружил валящийся в syslog лог. Полез в веб-морду - ожидаемо зависла. Разбираться не стал, ребутнул через ssh. Сегодня только дошли руки посмотреть, что же там роутер накидал в лог May 1 09:54:47 ndm: kernel: CPU 0 Unable to handle kernel paging request at virtual address 163cffac, epc == 80183de4, ra == 80183d70 May 1 09:54:47 ndm: kernel: Oops[#1]: May 1 09:54:47 ndm: kernel: Cpu 0 May 1 09:54:47 ndm: kernel: $ 0 : 00000000 00000065 163cffac 830c3e48 May 1 09:54:47 ndm: kernel: $ 4 : 163cffac 00000010 163d0000 ffffffeb May 1 09:54:47 ndm: kernel: $ 8 : 00000010 00000000 00000000 00000000 May 1 09:54:47 ndm: kernel: $12 : 77065d4c 00000807 00000000 00000000 May 1 09:54:47 ndm: kernel: $16 : 830c3e48 803000d8 000089ff 803000d8 May 1 09:54:47 ndm: kernel: $20 : 77065cfc 00000000 00000000 7787d2c0 May 1 09:54:47 ndm: kernel: $24 : 00000000 77964d00 May 1 09:54:47 ndm: kernel: $28 : 830c2000 830c3e00 770665f0 80183d70 May 1 09:54:47 ndm: kernel: Hi : 000000c9 May 1 09:54:47 ndm: kernel: Lo : 000b930c May 1 09:54:47 ndm: kernel: epc : 80183de4 dev_get_by_name_rcu+0xa4/0xfc May 1 09:54:47 ndm: kernel: Tainted: P O May 1 09:54:47 ndm: kernel: ra : 80183d70 dev_get_by_name_rcu+0x30/0xfc May 1 09:54:47 ndm: kernel: Status: 1100ec03 KERNEL EXL IE May 1 09:54:47 ndm: kernel: Cause : 00800008 May 1 09:54:47 ndm: kernel: BadVA : 163cffac May 1 09:54:47 ndm: kernel: PrId : 00019650 (MIPS 24KEc) May 1 09:54:47 ndm: kernel: Modules linked in: fastvpn(PO) hw_nat(O) mt76x2_ap(O) rtsoc_eth(PO) ip_set_hash_ip ip_set_hash_ipportip ip_set_hash_net ip_set_hash_ipport ip_set_hash_ipportnet ip_set_bitmap_port xt_set ip_set_bitmap_ipmac ip_set_hash_netiface ip_set_bitmap_ip ip_set_hash_netport ip_set_list_set usbextras(PO) nls_utf8 ip_set xt_IPMARK(O) nfsd xt_ACCOUNT(O) nls_cp1251 nfs usb_storage nfnetlink_log xt_DNETMAP(O) xt_length2(O) arptable_filter sd_mod ohci_hcd sr_mod nls_cp437 xt_DELUDE(O) xt_CHAOS(O) lockd auth_rpcgss sg ext4 xt_LOGMARK(O) nfnetlink_queue ebtable_broute xt_STEAL(O) nls_cp866 xt_ipp2p(O) xt_DHCPMAC(O) ebtable_filter jffs2 xt_psd(O) ebtable_nat ehci_hcd xt_TPROXY cifs xt_RAWNAT(O) xt_SYSRQ(O) xt_TARPIT(O) nf_conntrack_netlink usbcore ebt_redirect xt_geoip(O) xt_iprange xt_NOTRACK ipt_ULOG ip6t_rt xt_connbytes xt_addrtype xt_recent lzo_decompress ip6t_mh xt_string cdrom resetnds(PO) hmac ebt_dnat des_generic xt_iface(O) ebt_802_3 mtdoops_proc(O) nacct(PO) xt_comment nf_tproxy_c [...] May 1 09:54:47 ndm: kernel: Process ndm (pid: 135, threadinfo=830c2000, task=83d46d20, tls=7706e960) May 1 09:54:47 ndm: kernel: Stack : 7787d2c0 8018ada8 00000001 ffffffff 77065cdc 830c3e48 830c3e48 80186d44 May 1 09:54:47 ndm: kernel: 77065cfc 00000000 00000000 7787d2c0 77065cdc 8018b268 007ba000 83098ae0 May 1 09:54:47 ndm: kernel: 0000043c 80f66f40 32687465 00000000 00000000 00000000 77065d4c 00000000 May 1 09:54:47 ndm: kernel: 00000000 00000000 00000000 00000000 8383a8e0 77065cdc 000089ff 77065cdc May 1 09:54:47 ndm: kernel: 000089ff 77065cdc 00000000 7787d2c0 770665f0 800ad914 80f66f40 83890658 May 1 09:54:47 ndm: kernel: ... May 1 09:54:47 ndm: kernel: Call Trace: May 1 09:54:47 ndm: kernel: [<80183de4>] dev_get_by_name_rcu+0xa4/0xfc May 1 09:54:47 ndm: kernel: [<80186d44>] dev_load+0x14/0x9c May 1 09:54:47 ndm: kernel: [<8018b268>] dev_ioctl+0x34c/0x664 May 1 09:54:47 ndm: kernel: [<800ad914>] do_vfs_ioctl+0x48c/0x5c8 May 1 09:54:47 ndm: kernel: [<800ada98>] sys_ioctl+0x48/0x90 May 1 09:54:47 ndm: kernel: [<80011250>] stack_done+0x20/0x44 May 1 09:54:47 ndm: kernel: May 1 09:54:47 ndm: kernel: May 1 09:54:47 ndm: kernel: Code: 8fbf001c 00402021 01002821 May 1 09:54:47 ndm: kernel: 10a00006 90610000 24a5ffff 14270004 24840001 May 1 09:54:47 ndm: kernel: ---[ end trace fee9c31a07fa0035 ]--- May 1 09:54:48 ndm: Thread: failed to get thread 135 statistics: invalid argument. May 1 09:55:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 30 seconds. May 1 09:55:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 60 seconds acquired May 1 09:54:47. May 1 09:56:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 60 seconds. May 1 09:56:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 90 seconds. May 1 09:56:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 120 seconds acquired May 1 09:54:47. May 1 09:57:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 120 seconds. May 1 09:57:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 150 seconds. May 1 09:57:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 180 seconds acquired May 1 09:54:47. May 1 09:58:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 180 seconds. May 1 09:58:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 210 seconds. May 1 09:58:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 240 seconds acquired May 1 09:54:47. May 1 09:59:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 240 seconds. May 1 09:59:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 270 seconds. May 1 09:59:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 300 seconds acquired May 1 09:54:47. May 1 10:00:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 300 seconds. И так вплоть до ребута. Вот что было при обращении к веб-морде May 1 23:32:20 keenetic_omni nginx: 2018/05/01 23:32:20 [error] 407#0: *5257 upstream timed out (145: Unknown error) while reading response header from upstream, client: 192.168.0.10, server: my.keenetic.net, request: "POST /ci HTTP/1.1", upstream: "scgi://unix:/var/run/ndm.scgi.socket", host: "192.168.0.1:10080", referrer: "http://192.168.0.1:10080/" Ну и на закуску, сообщение о неясном баге, датированное сегодняшним днём (ночью) May 3 00:18:42 ndm: kernel: BUG: Bad page map in process ndm pte:126a5a1e pmd:830b8000 May 3 00:18:42 ndm: kernel: addr:00afb470 vm_flags:00100077 anon_vma:830a7c58 mapping: (null) index:afb May 3 00:18:42 ndm: kernel: Call Trace: May 3 00:18:42 ndm: kernel: [<8028247c>] dump_stack+0x8/0x34 May 3 00:18:42 ndm: kernel: [<80080fa8>] print_bad_pte+0x18c/0x208 May 3 00:18:42 ndm: kernel: [<80084620>] handle_pte_fault+0x2c8/0x834 May 3 00:18:42 ndm: kernel: [<80084c1c>] handle_mm_fault+0x90/0xe8 May 3 00:18:42 ndm: kernel: [<80012f28>] do_page_fault+0xb8/0x390 May 3 00:18:42 ndm: kernel: [<800099a0>] ret_from_exception+0x0/0x10 May 3 00:18:42 ndm: kernel: Apr 25 02:05:24 pppd[395]: Remote message: Authentication success,Welcome! Apr 25 02:05:24 pppd[395]: PAP authentication succeeded Прошивка 2.11.C.0.0-2
×