RUTX08 7.06.1 where is ubus call vuci.services.openvpn gone?

Networking Solutions
1

Hi,

not sure this has with the new version to do, but where is ubus call vuci.services.openvpn gone?

ubus list | grep vuci.

vuci.login
vuci.network.mobile
vuci.services.hotspot
vuci.services.services
vuci.system
vuci.system.certificates
vuci.system.firmware

We use “ubus call vuci.services.openvpn openvpn_status” in scripts to detect a working vpn connection…

Or has this something to do how the OpenVPN client was added?

Edit:
Same with RUTX_R_00.07.05.4

3

Hello,

Moving forward, RutOS API will be used to interact with the device, thus we suggest moving from ubus to the API for gathering information and changing the settings of the device.
API documentation can be found here:
https://developers.teltonika-networks.com/
However, it should be noted, that API is still in beta, thus some minor issues can still be expected. Endpoints should not change throughout the v1 release, and they will be supported even when v2 comes out.
For OpenVPN in particular, API call to /openvpn/status can be used and it will return all information visible in the WebUI, including:

  • OpenVPN status

  • Transmitted and received data

  • Logs

  • Remote IP address and more.

If the calls are done via the router itself, you can skip the authentication step and use the api command:

root@RUTX09:~# api --help
        This script allows calling api endpoint locally without using HTTP

        Usage: /sbin/api <http_method> <request_path> [<request_body>...]
        Example: /sbin/api PUT /interfaces/config '{"data":[{"id":"lan","netmask":"255.255.255.0"}]}'

For example, here is a VPN client configured:

root@RUTX09:~# /sbin/api GET /openvpn/status
{
  "http_body": {
    "success": true,
    "data": {
      "rms_FaEvQo9HCs2gpyLF": {
        "type": "0",
        "protocol": "tun",
        "ip6address_remote": "",
        "ip6address": "",
        "tx": "4873",
        "logs": "Tue Jan 16 09:21:00 2024 daemon.warn openvpn(rms_FaEvQo9HCs2gpyLF)[16261]: Multiple --down scripts defined....[16261]: Initialization Sequence Completed\n",
        "rx": "4717",
        "uptime": "00h 00m 18s",
        "updated": "2024-01-16 09:21:10",
        "status": "1",
        "ipaddress_remote": "192.168.255.5",
        "ipaddress": "192.168.255.6"
      }
    }
  },
  "http_code": 200

Hope this helps! In case any issues arise, let me know.

Best regards,

4

Thanks @Daumantas this was completely new for me.

At the moment I check the OpenVPN connection with:
if ifconfig | grep -q ‘VPNName’; then
fi

This works, but is it save for future?

And whats about “ubus call ioman.gpio.din1 status”, do this change as well?

We have RUTX08 around the world, if this functions do not work anymore all our bash scripts stop working…

Edit: For the gpio I started a new thread:

5

Hello,

The ifconfig command can be used, however, if you are planning to unify the scripts to use the new API, then the status could be obtained using the following command:

/sbin/api GET /openvpn/status | jsonfilter -e '@.http_body.data.*.status'

This command assumes there is only one OpenVPN client configured on the device. If you have more, then you could replace the star symbol by the name of the VPN tunnel. The output of the command will return either 0 (disconnected) or 1 (connected):

root@RUTX09:~# /sbin/api GET /openvpn/status | jsonfilter -e '@.http_body.data.*.status' 
0
root@RUTX09:~# /sbin/api GET /openvpn/status | jsonfilter -e '@.http_body.data.*.status'
1

As for GPIO, I currently do not have any information that the UBUS call will be removed, but if you’ll be moving to the new API, then the command to use to check the status of the digital input would be:

/sbin/api GET /io/status | jsonfilter -e '@.http_body.data[@.id="din1"].value'

Other pins will have different IDs.
API in combination with jsonfilter utility can be very powerful tools, and my provided examples can be optimized to suit your needs.
It should be noted, that using API (unlike ubus), the settings of the device can be changed as well. All calls can be found in the webpage provided in my first comment.

EDIT: It seems like there is an API call to get a specific GPIO pin status instead of using jsonfilter:

/io/{id}/status

Best regards,