I’ve been trying to use the RUT300 (firmware: RUT30X_R_00.07.12) through its API to add static IPv4 routes to the table whenever needed. I’m following the developers API documentation (https://developers.teltonika-networks.com/reference/7.6.10/v1/ip-routes/) which is working up to a point.
In fact I’m able to login and get a token, then use the POST command on the “/ip_routes/ipv4/config” endpoint to add my route which returns a success along with all my filled in fields and a newly created id number.
However after testing this route, it doesn’t work. Upon inspecting the ‘network>routing>static routes’ page in the WEBUI I can clearly see my newly added route with everything filled in correctly.
But after checking the ‘status>routes>static’ page I can’t see my new route. Also checking in CLI with ‘ip route’ shows me all the routes except the one I’ve added through its API.
The only thing I could think of was that it wasn’t saved or applied in some way. So going back to ‘network>routing>static routes’ and clicking on the “Save & Apply” button at the bottom actually solves the problem and everything is as expected.
Does anyone know how can I emulate the “Save & Apply” action through API? The documentation page I’ve supplied above doesn’t mention anything about this. Any ideas on this? the WEBUI itself seems to use api/bulk and then accessing the same endpoint I’m trying to use directly. But according to the documentation api/bulk shouldn’t be necessary for my purposes.
No when using API you do not need any “apply” requests as configuration reloads are handled automatically.
The issue comes when route cannot be created during runtime (e.g. gateway is unreachable) . Currently route creation during runtime errors cannot be gathered using API. At least now the best way to debug these problems is to manually create route using ip route add via CLI as this command will show why it cannot be created. Note: ip route uses phy devices and API uses interfaces so before calling route add check which device is being use by interface.
e.g:
root@RUTM11:~# ip route add 192.168.5.0/24 via 100.100.100.100 dev br-lan
RTNETLINK answers: Network unreachable
I’ve tried adding it via terminal with ssh using 'ip route add…" and it was successfully added when checking with “ip route”. I can even see it in my WEBUI on the status>routes>static page. But I can’t see it when i go to the page ‘network>routing>static routes’.
With this I would conclude that connection or network problems isn’t the issue?
At one point I was thinking it might be the user rights, but I’ve been testing with a user within the ‘root’ group the whole time. So I don’t think that might be the case.
(Edit: I can see now that the api works through “network>routing>static” page and that the CLI command works directly ofcourse. Somehow the api method is preventing to insert my route into the actual route list. )
No user right issues would produce errors on API request
Oh I did not saw that “Save & Apply” fixed it. As next thing you can check if WebUI did not modified route to get it working by checking before and after with cat /etc/config/network (newly created route should be at the bottom). If WebUI did not modified anything and made it to work can you show your API request that creates this miss behaving route?
newly created route (with API request) is showing at the bottom correctly
on the WEBUI page “network>routing>static” it also showing properly
However on the WEBUI page “status>routes>static” and in CLI “ip route” its still not showing up
I’ve gone ahead and added my route request anyway just to give some reassurance.
This is using Postman (generated a cURL snippet to paste here. This is all fake info, but still the same principle):
Found a bug that looks similar. For some reasons if you create "type": "unicast" and then change it with PUT to "type": "" (even though both mean same thing as unicast is default type) removes route from table and only network restart (/etc/init.d/network restart) fixes it. This happens if you call your request and after it you save using WebUI as it changes type to “” if it was “unicast”.
The problem that what you are telling is reverse of this: upon creating route it does not work and changing it’s type to “” fixes it. I could not reproduce this. Maybe your Interfaces has something to do with this. No idea.
newly created route (with API request) is showing at the bottom correctly
However on the WEBUI page “status>routes>static” and in CLI “ip route” its still not showing up