NEW PROYECT! OPENWRT UTILITY (windows)

#1

Hello everyone, as you saw in the title I am preparing an application to use my router more easily, with the most used options, the method I will use will be an SSH connection to send the corresponding commands, but I have several questions about how to do this, in a first instance I would like to know if there is a glossary of commands that can be useful, forgive ignorance and I am not very adept in the issue of linux and consoles, I will write in C#, I will share the software for all and If it becomes another utility for OPENWRT, any interested party will wait for your comments.
PS: It would be great if someone helps me with the icon design :stuck_out_tongue_winking_eye:

Loading web UI files from a CDN
Loading web UI files from a CDN
#2

Hello!

It's good idea but requires lot of thinking and analysis to figure out the most common functionality user would need and are manageable to implement with the "most common" options or parameters. Besides, things change from a device to another and form a setup to a setup, and of course there is error handling.

Take for example "start WiFi / Stop WiFi functionality you have there. At first it might be simple enough. But what if a user have more than one WiFi? Will you stop them all or the first one? Or will you retrieve a list of the WiFi's in runtime and populate it somewhere? Ad what if the user has no WiFis? So, you see, something simple will not suite an open firmware that's used in a wide variety of devices. And if you try to be through, then it will be like re-inventing the wheel, because LuCI is already there.

If you want to participate, then you could probably look for some useful packages that are there but have no GUI, and you develop GUI for them.

Or if you are mostly develop desktop applications then you could probably look into developing some interface for VPN clients. It could be useful to let people conveniently check the status of VPN connection and adjust it (e.g. change server) form the desktop.

It's worth mentioning that a big percentage of users here are probably on Linux, so a Windows application might not have lot of audience (well, there is mono project for Linux-based .Net framework but I never tired it), but then again, probably those on Linux don't need a desktop application to begin with!

2 Likes
#3

Why not interact with the API after going through that programming?

I would suggest panels where perhaps the UCI commands are displayed while configuring sections - to read before being uploaded/saved/applied to the router.

This would actually teach new users the UCI CLI commands as they progress. Perhaps also adding the relevant UCI file syntax as an option is good; but, that may be more advanced to program, though.

3 Likes
#4

How is this better than the current web interface? Why a new interface, instead of improving the current one?

6 Likes
#5

Actually I've been thinking about a similar approach, for routers which have not enough flash/ram to run Luci. I was thinking, AFAIK Luci is some CGI script which calls uci or libuci for communication with the router.
What if you'd write a small layer which translates the direct uci calls to a call over ssh to the router? In that case Luci could run on a separate device, a Windows box possibly, and the footprint on the router could be much smaller.

6 Likes
#6

I think luci already uses a similar layer called ubus. Though ubus uses a unix socket (/var/run/ubus.sock) but you could use socat to connect to it via tcp.

Edit: I made a quick test and it seems to work, at least adding a static route did work.
On the "slave" in executed:

socat -t100 TCP-LISTEN:1234,reuseaddr,fork UNIX-CONNECT:/var/run/ubus.sock

and on the "master" running luci:

mv /var/run/ubus.sock /var/run/ubus.sock.orig; socat -t100 UNIX-LISTEN:/var/run/ubus.sock,mode=777,reuseaddr,fork TCP-CONNECT:<slave IP address>:1234

The TCP connection is unprotected in this test!

2 Likes
#7

You read my mind! I have some bits and pieces and would be interested on contributing should this proceed along these lines. ( maybe a new post if anyone is really keen )

It entirely possible to throw the C# interface or any other atop :slight_smile:

From my end.... that is http-php.... only because that's where i'm comfortable.... and it's testable directly on the device.... side stepping the middleware.

ubus socket is control != config correct?

there is also that..... always forget the name..... existing software that does something similar.... i think it's perl / python based maybe.... not sure how "up to date" it is.... it's not mentioned much and it's aimed at large setups... a bit too complex for me ...

1 Like
#8

@mikma: I looked at the lua scripts, and it seems all calls to ubus are routed via utils.lua to (/usr/lib/lua/)ubus.so. So the 'only' thing to do is adapt ubus.so to use TCP sockets instead of unix sockets, and done.
The remote Luci interface sets up an ssh connection to run socat on the other side, tunnels that to localhost, and the adapted ubus.so uses that.

In practise it will be a bit harder. On my box I have this binaries in /usr/lib/lua: iwinfo.so,
ip.so, jsonc.so, parser.so, lucihttp.so, nixio.so and ubus.so

@wulfy23: If you rewrite the interface in C#, or whatever, there are 2 codebases implementing the same functionality, one in C#, and one in Lua. Both have to be maintained. It's easier to maintain if both interfaces can share the majority of the code. Lua runs on Windows (and all other platforms I'm aware of).

Not sure. Luci is able to adapt the config files in /etc/config, which have a strong relation with uci. Normally I'd say the web backend cannot adapt that files directly due to permissions, and so it has to be done through ubus. But on OpenWrt the webinterface runs as root, and for some reason it has a jsonc.so. So maybe config is not done through ubus?

1 Like
#9

I was able to configure a static route via the socat socket forwarding anyway.

1 Like
#10

thanks to all guys for giving their opinion, and if many are right would be like reinventing the wheel, luci is already quite friendly, but in my case I need it and I think also router without enough RAM, I will continue with the project I have been given many ideas new and I will have to try them all, the goal is to go through the way that more configurations offer me even I was thinking that also by several ways, I do not know, editing the config file through SCP I think there is a module for NET, such as SSH, or simply by UCI commands, it would be very helpful if you would list the most important functions that would be needed, in my case with:
-to disable / enable wifi,
-change the ip of the LAN
-restart WAN interface
-reboot router
-Update the firmware
-Make a Backup
-Change the parameters of the wifi (like SSID, BSSID, etc)
It will be enough, from the first moment I will work with these variables.
Thanks for the support

1 Like
#11

prior to that you have to take into consideration model variations.

uci - configs ... etc. are model / version dependant in some cases.

so define a limited scope with relation to what your plans are in this area

a) try to support most minor variances within reason.... from 18.06.2 onwards

b) support only your available devices with scope to add

c) ........ etc.

it's mostly network differences.... initially i'm referring to here.... but there are others.....

to this extent.... i'd suggest a nice debug subroutine first up that you can include in most of your calls that spits out relationally similar configs / uci settings....

this way when you hit these variations they will be handled and the majority of the groundwork will be automajic.

fwiw... execution over ssh does not lend itself to detailed feedback and debugging.... i've been working with this over the last week....

glad to hear your plan is proceeding and i'm sure many here will be glad to help when it comes to overcoming specific hurdles .... when ( if :wink: ) they arise.... :slight_smile:

#12

Try lookin up the wifi pineapple. You may find some insight looking at the ssh module created for it.

1 Like
#13

wouldn't it be easier to run luci as an APP in Windows/Linux/Mac ?

#14

Or run luci on a R-Pi. Flash routers as routers or APs and then the R-Pi as a controler for the hole network.

#15

Neither would be an easy job.

1 Like
#16

As others have pointed out, there's a lot of functionality one needs to cover to replicate what the web UI offers. VLANs, multiple interfaces (LAN, WAN, VPN and WiFi), etc…

I'm not sure if there's some way for the UCI back-end to describe what the UI should look like or whether that gets baked into the front-end (LUCI in most cases), but it would appear the UCI back-end provides much of the abstraction that you'd need to make the C# front-end possible.

socat was mentioned earlier, which could be used one of two ways:

  • bridging the Unix-domain socket used by UCI to a TCP socket
  • bridging the Unix-domain socket used by UCI to the stdio stream

The latter option could work if you can work interactively with the connection generated by your SSH library. Otherwise, I'd be getting socat to open a port on the target router (bound to the loop-back interface), then tell the SSH library to forward the port being used by socat to some local port on your local machine (also bound to loop-back) which your C# application would then connect.

No idea how feasible either option is with the C# development environments… I've dealt with C# about 3 times in the 19 years it has existed and so far have not warmed to it as a programming language. (To say it has sharp edges, is putting it bluntly.) I jump between a lot of other languages (C, C++, Java, Python, JavaScript) and so far have rarely had a need to settle my differences with the .NET environment. A big driver in my case is I rarely touch Windows -- don't have much time these days for an OS that simultaneously can't make up its mind about whether it's pretending to be VMS, CP/M or (more recently) Linux.

Maybe as a starting point, you could try seeing if you can make a program that can connect via SSH, launch wpa_cli and interact with that to dump a list of the local WiFi networks -- that might tell you enough about how to tackle communicating with UCI via socat.

You'd then be implementing the protocols being used on that socket before producing the front-end to make it all user-friendly.