Jump to content
  • 0

Вопросы по /rci


dvg_lab

Question

Накопилось некоторое количество вопросов по интерфейсу /rci, и так как пока не готов мануал по rci, буду задавать вопросы здесь в отдельном треде и надеюсь на помощь сообщества:

Создаю правило в МСЭ через веб морду и смотрю как формируется JSON, например интерфейс OpenVPN0, на котором не было ни одного правила в первых строках удаляет вроде бы не существующий access-list

[{"access-list":
	{
    	"acl":"_WEBADMIN_OpenVPN0",
     	"no":true
    }
 },
 {
 	"access-list":
    	[{"permit":
       		{"source":"0.0.0.0",
... далее понятно

И ответ подтверждает удаление "message": "_WEBADMIN_OpenVPN0" access list removed."

Вопрос, это необходимая процедура перед началом создания первого правила на интерфейсе, сначала удалить, а потом он автоматически создастся при первом же permit/deny правиле?

И второй вопрос, можно ли одним JSON запросом сформировать сразу все правила (у меня их около 18) на все интерфейсы и тем же запросом сказать {"system":{"configuration":{"save":true}}} ?

Link to comment
Share on other sites

29 answers to this question

Recommended Posts

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

Накопилось некоторое количество вопросов по интерфейсу /rci, и так как пока не готов мануал по rci, буду задавать вопросы здесь в отдельном треде и надеюсь на помощь сообщества:

Создаю правило в МСЭ через веб морду и смотрю как формируется JSON, например интерфейс OpenVPN0, на котором не было ни одного правила в первых строках удаляет вроде бы не существующий access-list


[{"access-list":
	{
    	"acl":"_WEBADMIN_OpenVPN0",
     	"no":true
    }
 },
 {
 	"access-list":
    	[{"permit":
       		{"source":"0.0.0.0",
... далее понятно

И ответ подтверждает удаление "message": "_WEBADMIN_OpenVPN0" access list removed."

Вопрос, это необходимая процедура перед началом создания первого правила на интерфейсе, сначала удалить, а потом он автоматически создастся при первом же permit/deny правиле?

И второй вопрос, можно ли одним JSON запросом сформировать сразу все правила (у меня их около 18) на все интерфейсы и тем же запросом сказать {"system":{"configuration":{"save":true}}} ?

1. Нет, эта процедура скоро станет необязательной. Как раз сейчас способ сохранения правил переделывается. Это запрос удаляет цепочку ACL целиком.

2. При сохранении правила цепочка будет создана автоматически. Чтобы сохранить несколько правил -- отсылайте правила массивом, в каждом элементе -- запрос для отдельного интерфейса с массивами в permit и deny

Точную форму запроса можно найти, экспериментируя в Web CLI: my.keenetic.net/a (вкладка REST)

  • Upvote 2
Link to comment
Share on other sites

  • 0

Спасибо огромное, а за ссылку на /a отдельное спасибо, не знал, а теперь все гораздо проще!

По новому способу хранения правил, значит перед тем как отправлять правила в /rci нужно будет еще и версию release проверять, подскажите с какой версии поменяется алгоритм хранения?

 

Link to comment
Share on other sites

  • 0
16 минут назад, dvg_lab сказал:

Спасибо огромное, а за ссылку на /a отдельное спасибо, не знал, а теперь все гораздо проще!

По новому способу хранения правил, значит перед тем как отправлять правила в /rci нужно будет еще и версию release проверять, подскажите с какой версии поменяется алгоритм хранения?

 

Изменения попадут в 2.14. При создании списка с нуля (или удалении первой командой) -- ничего не поменяется.

  • Thanks 1
Link to comment
Share on other sites

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

Изменения попадут в 2.14. При создании списка с нуля (или удалении первой командой) -- ничего не поменяется.

А как происходит процедура, когда правило надо втиснуть меж других правил? ...удаляется хвост вписывается правило и добавляется хвост из правил?

Link to comment
Share on other sites

  • 0
28 минут назад, MDP сказал:

А как происходит процедура, когда правило надо втиснуть меж других правил? ...удаляется хвост вписывается правило и добавляется хвост из правил?

Прямо сейчас -- удаляем все, сохраняем новый список целиком

  • Thanks 1
Link to comment
Share on other sites

  • 0
Только что, eralde сказал:

Прямо сейчас -- удаляем все, сохраняем новый список целиком

Это приводит к проблемам у некоторых пользователей, поэтому и переработали механизм сохранения.

  • Thanks 1
  • Upvote 1
Link to comment
Share on other sites

  • 0

Запихиваю вот такой JSON

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



[
    {
        "access-list": {
            "acl": "_WEBADMIN_OpenVPN0",
            "no": "True"
        }
    },
    {
        "access-list": [
            {
                "permit": {
                    "disable": "False",
                    "source-mask": "0.0.0.0",
                    "_": "0",
                    "destination": "0.0.0.0",
                    "schedule": {
                        "no": "True"
                    },
                    "acl": "_WEBADMIN_OpenVPN0",
                    "protocol": "ip",
                    "index": "0",
                    "destination-mask": "0.0.0.0",
                    "action": "permit",
                    "source": "0.0.0.0"
                }
            }
        ]
    },
    {
        "interface": {
            "OpenVPN0": {
                "ip": {
                    "access-group": [
                        {
                            "direction": "in",
                            "acl": "_WEBADMIN_OpenVPN0"
                        }
                    ]
                }
            }
        }
    },
далее идут остальные интерфейсы и сохранение


 

Правила попадают на свои интерфейсы и отображаются в веб интерфейсе, все нормально, но они все в состоянии "Выключено", несмотря на параметр "disable":"False"

Вроде никакого специфичного запроса на включение больше не отлавливается.

Что нужно сделать чтобы они заенаблились? 

Link to comment
Share on other sites

  • 0
2 минуты назад, dvg_lab сказал:

Запихиваю вот такой JSON

  Скрыть содержимое

 



[
    {
        "access-list": {
            "acl": "_WEBADMIN_OpenVPN0",
            "no": "True"
        }
    },
    {
        "access-list": [
            {
                "permit": {
                    "disable": "False",
                    "source-mask": "0.0.0.0",
                    "_": "0",
                    "destination": "0.0.0.0",
                    "schedule": {
                        "no": "True"
                    },
                    "acl": "_WEBADMIN_OpenVPN0",
                    "protocol": "ip",
                    "index": "0",
                    "destination-mask": "0.0.0.0",
                    "action": "permit",
                    "source": "0.0.0.0"
                }
            }
        ]
    },
    {
        "interface": {
            "OpenVPN0": {
                "ip": {
                    "access-group": [
                        {
                            "direction": "in",
                            "acl": "_WEBADMIN_OpenVPN0"
                        }
                    ]
                }
            }
        }
    },
далее идут остальные интерфейсы и сохранение

 

 

 

 

Правила попадают на свои интерфейсы и отображаются в веб интерфейсе, все нормально, но они все в состоянии "Выключено", несмотря на параметр "disable":"False"

Вроде никакого специфичного запроса на включение больше не отлавливается.

Что нужно сделать чтобы они заенаблились? 

Попробуйте 

"disable": false
  • Thanks 1
Link to comment
Share on other sites

  • 0
1 минуту назад, eralde сказал:

Попробуйте 


"disable": false

аналогично с schedule

true/false -- не строковые константы, а зарезервированные значения для булевого типа

  • Thanks 1
Link to comment
Share on other sites

  • 0
57 минут назад, eralde сказал:

аналогично с schedule

true/false -- не строковые константы, а зарезервированные значения для булевого типа

Все получилось, спасибо, на perl если кто столкнётся булев тип в хеше устанавливается так {"disable" => \0} и потом функция JSON->new->utf8->encode() обрабатывает это корректно в false, а true это соотв \1.

Link to comment
Share on other sites

  • 0

Запрашиваю POST'ом /rci/components/list 

и не пойму почему, но иногда, (чаще после какого-то значительного простоя ,  минут 20 по ощущениям), между GET/POST запросами роутер отвечает кодом 200 и таким контентом:

'_content' => '{                                                                                                
  "continued": true                                                                                                              
}',

При этом следующий такой же запрос уже отвечает по полной форме. Это куда копать? 

 

И еще вопрос, подскажите как в JSON переводится команды "no ip nat" и "ip static Home ISP", чего-то не могу подобрать правильный формат.

Edited by dvg_lab
Link to comment
Share on other sites

  • 0
14 часа назад, dvg_lab сказал:

Запрашиваю POST'ом /rci/components/list 

и не пойму почему, но иногда, (чаще после какого-то значительного простоя ,  минут 20 по ощущениям), между GET/POST запросами роутер отвечает кодом 200 и таким контентом:


'_content' => '{                                                                                                
  "continued": true                                                                                                              
}',

При этом следующий такой же запрос уже отвечает по полной форме. Это куда копать? .

Есть ряд команд, которые работают долго, поэтому возвращают такой статус если еще не могут выдать ответ. Для них после первого POST-запроса нужно продолжать посылать GET-запросы на тот же ресурс (URL) пока не будет получен ответ без признака continued -- это и будут нужные вам данные.

 

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

И еще вопрос, подскажите как в JSON переводится команды "no ip nat" и "ip static Home ISP", чего-то не могу подобрать правильный формат.

 В такой форме:

{ip: {nat: {no: true}}}

должно сработать.

 

Во втором случае проще всего посмотреть, что отвечает роутер по GET-запросу rci/ip/static если такое правило создать в CLI (или через веб-интерфейс)

Вот такой POST-запрос на адрес rci/ создает нужное правило:

{
    "ip": {
        "static": {
            "interface": "Home",
            "to-interface": "ISP"
        }
    }
}

 

  • Thanks 1
Link to comment
Share on other sites

  • 0

Спасибо огромное еще раз! По continued так и сделал, закциклил до нужного ответа. 

С ip static все получилось, намедни правда применил хак, отправил POST к /rci с таким запросом {"parse":"ip static Home ISP"} и это сработало, подсмотрел в /a на вкладке Parse ))

После того как увидел спросил сам себя - А что так можно было?... ))

Вобщем теперь роутер настраивается перловым скриптом за 5 минут, следующий этап прикрутить к нему веб морду и отдать в эксплуатацию.

 

ЗЫЖ Чем лучше сохошный кинетик для кровавого энтерпрайза, чем тот же ZyWall или Cisco  810 и даже RV320, а тем что кинетик можно купить в первом попавшемся магазине. Натравить на него конфигурилку, заббикс и вот тебе корп. VPN сеть для розничных точек. Раньше мне приходилось билдить прошивки для Асусов (RT-N16 и иже с ними), вкорячивать OpenVPN, обвязку и тд, и дохли те асусы словно мухи, ну а теперь красота. Одна печаль 8-портовую Ultra II похоронили, не найти уж в магазинах, успели только 10шт отхватить.

Link to comment
Share on other sites

  • 0

Подскажите пожалуйста как в rci правильно передать одной командой:

interface WifiMaster0/WifiStation0 down
interface WifiMaster0/WifiStation0 authentication wpa-psk ***
interface WifiMaster0/WifiStation0 ssid ***
interface WifiMaster0/WifiStation0 description ***
interface WifiMaster0/WifiStation0 up

 

Edited by Илья Ганжин
Link to comment
Share on other sites

  • 0
16 часов назад, Илья Ганжин сказал:

Подскажите пожалуйста как в rci правильно передать одной командой:

interface WifiMaster0/WifiStation0 down
interface WifiMaster0/WifiStation0 authentication wpa-psk ***
interface WifiMaster0/WifiStation0 ssid ***
interface WifiMaster0/WifiStation0 description ***
interface WifiMaster0/WifiStation0 up

 

Можно передавать массив команд parse:

[
    {
        "parse": "interface WifiMaster0/WifiStation0 down"
    },
    {
        "parse": "interface WifiMaster0/WifiStation0 authentication wpa-psk 12345678"
    },
    {
        "parse": "interface WifiMaster0/WifiStation0 ssid ***"
    },
    {
        "parse": "interface WifiMaster0/WifiStation0 description ***"
    },
    {
        "parse": "interface WifiMaster0/WifiStation0 up"
    }
]

 

Можно передать массив объектов:

[
    {
        "interface": {
            "WifiMaster0/WifiStation0": {
                "up": false
            }
        }
    },
    {
        "interface": {
            "WifiMaster0/WifiStation0": {
                "authentication": {
                    "wpa-psk": {
                        "psk": "12345678"
                    }
                }
            }
        }
    },
    {
        "interface": {
            "WifiMaster0/WifiStation0": {
                "ssid": "***"
            }
        }
    },
    {
        "interface": {
            "WifiMaster0/WifiStation0": {
                "description": "***"
            }
        }
    },
    {
        "interface": {
            "WifiMaster0/WifiStation0": {
                "up": true
            }
        }
    }
]

 

  • Upvote 4
Link to comment
Share on other sites

  • 0

Спасибо, я пробовал вчера первый вариант, но мне какую то ошибку выдавало

Я сделал двумя скриптами

shell_command:
  keenetic_w91: bash /opt/var/lib/homeassistant/91.sh
  keenetic_w95: bash /opt/var/lib/homeassistant/95.sh

Edited by Илья Ганжин
Link to comment
Share on other sites

  • 0
6 часов назад, eralde сказал:

Можно передавать массив команд parse:

Вот так почему то не работает, не подключается к сети

rest_command:
  keenetic_91:
    url: http://192.168.10.1:81/rci
    method: POST
    payload: '[{"parse": "interface WifiMaster0/WifiStation0 down"},{"parse": "interface WifiMaster0/WifiStation0 authentication wpa-psk ***"},{"parse": "interface WifiMaster0/WifiStation0 ssid idnet-91"},{"parse": "interface WifiMaster0/WifiStation0 description idnet-91"},{"parse": "interface WifiMaster0/WifiStation0 up"}]'

Link to comment
Share on other sites

  • 0
15 часов назад, Илья Ганжин сказал:

Вот так почему то не работает, не подключается к сети

rest_command:
  keenetic_91:
    url: http://192.168.10.1:81/rci
    method: POST
    payload: '[{"parse": "interface WifiMaster0/WifiStation0 down"},{"parse": "interface WifiMaster0/WifiStation0 authentication wpa-psk ***"},{"parse": "interface WifiMaster0/WifiStation0 ssid idnet-91"},{"parse": "interface WifiMaster0/WifiStation0 description idnet-91"},{"parse": "interface WifiMaster0/WifiStation0 up"}]'

Не хватает слэша после rci: http://192.168.10.1:81/rci/

Link to comment
Share on other sites

  • 0

Добрый день, подскажите, пожалуйста, а как сечас послать POST или parse через скрипт?
раньше я делал так:

#!/bin/sh
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/bin:/opt/sbin

curl --header "Content-Type: application/json" \
  --request POST \
  --data '
{
    "system": {
        "configuration": {
            "save": true
        }
    }
}' \
http://127.0.0.1:79/rci

Сейчас этот код выдает ошибку

Core::Scgi::Session: unsupported method "POST" for "/rci".

 

Link to comment
Share on other sites

  • 0
3 минуты назад, phntms сказал:

Добрый день, подскажите, пожалуйста, а как сечас послать POST или parse через скрипт?
раньше я делал так:

#!/bin/sh
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/bin:/opt/sbin

curl --header "Content-Type: application/json" \
  --request POST \
  --data '
{
    "system": {
        "configuration": {
            "save": true
        }
    }
}' \
http://127.0.0.1:79/rci

Сейчас этот код выдает ошибку

Core::Scgi::Session: unsupported method "POST" for "/rci".

 

Попробуйте добавить слэш в конце (/rci/)

Link to comment
Share on other sites

  • 0
5 minutes ago, eralde said:

Попробуйте добавить слэш в конце (/rci/)

уже лучше :)
 

~ # /opt/etc/script.sh
<html>
<head>
</head>
<body>
<h1>400: Bad Request</h1>
</body>
</html>~ #
Core::Scgi::ThreadPool: unable to parse JSON (http/rci).
Core::Scgi::Tools: bad request: invalid payload.
Core::Scgi::ThreadPool: unable to parse JSON (http/rci).
Core::Scgi::Tools: bad request: invalid payload.

 

Link to comment
Share on other sites

  • 0
11 минуту назад, phntms сказал:

уже лучше :)
 

Что-то с экранированием, наверное. У меня однострочный вариант работает:

/ # echo $SHELL
/bin/ash
/ # curl --header "Content-Type: application/json" --request POST --data '{"system": {"configuration": {"save": true}}}' http://127.0.0.1:79/rci/
{
  "system": {
    "configuration": {
      "save": {
        "status": [
          {
            "status": "message",
            "code": "8912996",
            "ident": "Core::System::StartupConfig",
            "message": "saving (http/rci)."
          }
        ]
      }
    }
  }
}/ #

 

Link to comment
Share on other sites

  • 0

Спасибо. Да, curl отрабатывает как надо. Буду разбираться в чем проблема.

~ # curl --header "Content-Type: application/json" --request POST --data '{"syst
em": {"configuration": {"save": true}}}' http://127.0.0.1:79/rci/
{
  "system": {
    "configuration": {
      "save": {
        "status": [
          {
            "status": "message",
            "code": "8912996",
            "ident": "Core::System::StartupConfig",
            "message": "saving (http/rci)."
          }
        ]
      }
    }
  }

 

Link to comment
Share on other sites

  • 0

@eralde возможно ли с помощью GET-запроса выключить/включить определенный интерфейс?

С помощью POST-запроса все получается, но интересно, реализуемо ли это через GET.

Пробовал "конструкцию" вида: 
http://192.168.1.1/rci/interface?name=WifiMaster0/AccessPoint1&up=false
Но, судя по всему, или что-то упустил, или делаю не так - система просто отвечает текущей конфигурацией этого интерфейса в JSON формате:

Скрытый текст
{
  "WifiMaster0/AccessPoint1": {
    "rename": "GuestWiFi",
    "description": "Guest access point",
    "mac": {
      "access-list": {
        "type": "none"
      }
    },
    "security-level": {
      "private": true
    },
    "authentication": {
      "wpa-psk": {
        "psk": "*"
      }
    },
    "encryption": {
      "enable": true,
      "wpa2": true,
      "tkip": {
        "hold-down": "*"
      }
    },
    "ip": {
      "dhcp": {
        "client": {
          "hostname": "*"
        }
      },
      "mtu": "1500"
    },
    "ssid": "*",
    "wmm": true,
    "rrm": true,
    "ft": {
      "mdid": "*",
      "enable": true
    },
    "up": true
  }
}
Link to comment
Share on other sites

  • 0
30 минут назад, dimon27254 сказал:

@eralde возможно ли с помощью GET-запроса выключить/включить определенный интерфейс?

С помощью POST-запроса все получается, но интересно, реализуемо ли это через GET.

Пробовал "конструкцию" вида: 
http://192.168.1.1/rci/interface?name=WifiMaster0/AccessPoint1&up=false
Но, судя по всему, или что-то упустил, или делаю не так - система просто отвечает текущей конфигурацией этого интерфейса в JSON формате:

  Показать содержимое

Нет, GET-запросы работают только на чтение конфигурации или текущего статуса.

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

  • Thanks 1
Link to comment
Share on other sites

  • 0
2 часа назад, Илья Ганжин сказал:

Подскажите где можно получить информацию о наличии обновлений прошивки?

Запрашивайте components list (<IP_или_доменное_имя_Кинетика>/rci/components/list). Эта команда запускает фоновый процесс, запрашивающий данные у сервера обновлений, поэтому первым отправляете POST-запрос, а дальше опрашиваете тот же URL GETом, пока не получите в ответе что-то кроме {"continued": true}. В финальном JSON с набором компонентов будет что-то такое:
 

image.png

Если версии отличаются, значит обновление есть (на моем скриншоте данные для случая, когда обновления нет).

В первом POST-запросе можно передать (необязательный) параметр sandbox -- канал обновления прошивки (stable/preview/drаft), тогда вернутся данные для запрошенного канала. Без параметра вернутся данные для выбранного на устройстве канала обновления.

Link to comment
Share on other sites

  • 0
В 23.05.2024 в 12:50, eralde сказал:

 

components check-update вроде бы тоже показывает наличие обновлений, но я что то не пойму как выполнить эту команду, http://192.168.10.1:81/rci/show/components/check-update не работает

Link to comment
Share on other sites

  • 0
3 часа назад, Илья Ганжин сказал:

components check-update вроде бы тоже показывает наличие обновлений, но я что то не пойму как выполнить эту команду, http://192.168.10.1:81/rci/show/components/check-update не работает

Слово show в URL не нужно, эта команда работает аналогично components list: сначала нужен POST-запрос, затем периодические GET-запросы до ответа с данными

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...