Jump to content
  • 0

Не все curl'ы одинаково полезны или проблемы с API


OmegaTron

Question

Итак, началось всё с того, что я набросал на машине под никсами команду для работы с API роутера 

curl -s --digest --user  xxx:xxx "http://192.168.1.1:10080/ci" -H "Content-Type: application/xml" --data-binary '<request id="1"><command name="show interface"><name>PPPoE0</name></command></request>'


после чего я экстраполировал её под win-версию curl'a

curl -s --digest --user  xxx:xxx "http://192.168.1.1:10080/ci" -H "Content-Type: application/xml" --data-binary "<request id="""1"""><command name="""show interface"""><name>PPPoE0</name></command></request>"


вот только ничего не заработало, на выхлопе я получал

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>Web server</center>
</body>
</html>

При использовании

<request id="1"><command name="show interface"><name>PPPoE0</name></command></request>

внутри файла для "data-binary" результат был тем же - 400 Bad Request. Начал копать - снял дампы на машинах и судя по ним, содержимое запроса было идентично, отправленному с машины на никсах вплоть до байта

0000   3c 72 65 71 75 65 73 74 20 69 64 3d 22 30 22 3e  <request id="0">
0010   3c 63 6f 6d 6d 61 6e 64 20 6e 61 6d 65 3d 22 73  <command name="s
0020   68 6f 77 20 69 6e 74 65 72 66 61 63 65 22 3e 3c  how interface"><
0030   6e 61 6d 65 3e 50 50 50 6f 45 30 3c 2f 6e 61 6d  name>PPPoE0</nam
0040   65 3e 3c 2f 63 6f 6d 6d 61 6e 64 3e 3c 2f 72 65  e></command></re
0050   71 75 65 73 74 3e                                quest>

Отличались лишь параметры авторизации, что логично, но вот поле realm отличалось радикально, на машине с никсами оно было

realm="ZyXEL Keenetic Omni II"

а на машине с win

realm=""

в чём тут причина я так и не понял, может местные спецы объяснят. Юзаемый curl

curl 7.42.1 (i386-pc-win32) libcurl/7.42.1 OpenSSL/1.0.2a zlib/1.2.8 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz

на никсах был менее "навороченный" вариант ревизии 7.34

Далее скачал этот релиз, http://winampplugins.co.uk/curl/ зарядил

<request id="1"><command name="show interface"><name>PPPoE0</name></command></request>

в файл и роутер мне таки отдал XML, зарядил

"<request id="""1"""><command name="""show interface"""><name>PPPoE0</name></command></request>"

и на выхлопе не получил ничего, только вот роутер начал плеваться в лог

02-01-2018    19:27:08    User.Critical    192.168.1.1    Feb  1 19:26:18 ndm: Core::Scgi::ThreadPool: system failed [0xcffd01da], XML parsing failed.
02-01-2018    19:27:08    User.Error    192.168.1.1    Feb  1 19:26:18 ndm: Xml::Document: ' or " expected.

а в дампах какая-то каша вместо запроса.

К слову, реакция на

"<request id="1"><command name="show interface"><name>PPPoE0</name></command></request>"

была идентичной

в итоге плюнул, скачал релиз на базе cygwin отсюда https://bintray.com/vszakats/generic/curl/ и всё заработало ! И

"<request id="""1"""><command name="""show interface"""><name>PPPoE0</name></command></request>"

в "data-binary" и

<request id="1"><command name="show interface"><name>PPPoE0</name></command></request>

отдаваемом в файле для параметра "data-binary".

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

Edited by OmegaTron
Link to comment
Share on other sites

17 answers to this question

Recommended Posts

  • 1

Ну во-первых: http://keenetic-gi.ga/2017/06/28/core-interaction/

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

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

Link to comment
Share on other sites

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

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

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

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

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

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

Link to comment
Share on other sites

  • 0

Ну и раз пошла такая пьянка - почему нигде не упоминается работа с 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 в разы проще парсить

Link to comment
Share on other sites

  • 0
В 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 с вкл/откл интерфейсов проблем нет.

Link to comment
Share on other sites

  • 0
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 у меня подручными средствами не получится.

Link to comment
Share on other sites

  • 0
4 часа назад, OmegaTron сказал:

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


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 у меня подручными средствами не получится.

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

Link to comment
Share on other sites

  • 0
22 часа назад, Le ecureuil сказал:

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

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

{"123":false}

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

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

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

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

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

Edited by OmegaTron
Link to comment
Share on other sites

  • 0

Le ecureuil, когда появится мануал - если не затруднит, маякните в данной теме или в ЛС, либо скажите, где его искать потом.

Link to comment
Share on other sites

  • 0

Мануал до сих пор в процессе ? После обновления с 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 юзать не комильфо. Чего там опять наворотили ?

Edited by OmegaTron
Link to comment
Share on other sites

  • 0
3 часа назад, OmegaTron сказал:

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

Скрытый текст

/opt/bin # ndmq -p 'show ip hotspot' -x | xml sel -t -m '//host[link="up"][active="yes"]' -v 'name' -o ' : ' -v 'ip' -o ' : ' -v 'rxbytes' -o ' : ' -v 'txbytes'

I-Bit : 192.168.130.18 : 8650 : 1533
Home-Ps : 192.168.130.2 : 2145923 : 445117
Gg : 192.168.130.98 : 21624 : 59672
S-43 : 192.168.130.20 : 1781135 : 184823
/opt/bin # 

 

 

Link to comment
Share on other sites

  • 0

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

Edited by OmegaTron
Link to comment
Share on other sites

  • 0
В 13.10.2018 в 01:48, OmegaTron сказал:

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

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

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

Если нужно с авторизацией, то через ip http proxy, можно еще и ssl приделать.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...