Client Luci - Configure multiple devices

Feature Requests
1

As the title is 2 parts, so are the concepts.

"Configure multiple devices" is part 2, and relies on part 1 "Client Luci" (off device hosted Luci). Part 1 is the primary focus, and part 2 is not intended to be implemented in the same fashion as many are used to. (OpenWisp, etc)

I have been tracking multiple forum posts and external info regarding managing multiple OpenWRT devices for awhile now.

Beating a dead horse you say?....maybe not.

While certainly there are 3rd party options out there (openwisp, Ansible, openwrt-configurator,Dusk, cucumberwifi, etc), they are usually heavy, often bloated, and just one more link in the chain to train on, update, manage, or break. It seems potentially, the more efficient answer may be right under our noses.

Have Luci hosted locally on the controller machine, where horsepower and a modern browser are already the requirement.

With luci-1 that wasn’t realistic, however now that Luci2 is now almost all client side JS anyway, moving Luci off device seems more logical.

Tunneling the JSON-RPC stream to the local browser, from the device, means less device resource usage than directly serving the luci pages that could be run (and most are already – aka JS-XHR rendered) on the host. That would also mean that uhttpd may not even be needed on the device, further reducing resource requirements.

Some Advantages:

OpenWRT team controlled, consistent & Familiar UI – no adding layers of security risk / learning curve / bloat

Allow smaller on device images (aka:more devices now usable) while keeping Luci available for consistent configurations

Same UI whether on-device Luci or controller hosted Luci

Maintains Cross platform Luci capability

Maintains language localization for devices while decreasing image size

Configure/manage single or multiple devices (batch style) from one host. (This will eventually have to be a whole separate post, but as it requires off device Luci, it is started here.)

Access to local package repos/configs/images/documentation or other content on host machine.

Provide browser proxy internet connection: package installs / device provisioning for devices without direct internet connection.
(ref github.com/httptoolkit/mockttp#readme)

Lower attack vectors:
single RPC tunnel instead of multi http connections (beacons)
add optional keyfile auth for tunneling in leu of password
Could use SPA with reverse tunnel instead of always open HTTS port
possible single hardened Luci-only controller on lan or node
lan/node devices need no internet connection if desired –
(host repos or proxy thru host browser)

Future Luci apps/modules can extend fleet management and other heavier lift functionality you would not usually attempt on the lower end hardware.

And yes, if desired, you could still run Openwisp or the likes on the luci controller, or any other web hosted content/apps for that matter.

The concepts here are about leveraging the small, light, and fast Luci to reach higher utility and user efficiency, while minimizing device image size, resource requirements, and code changes.

Its also about consistency, and extending an already mature framework in active development, with a large app/module contributor base.

Hopefully we can get the absolutely amazing Devs here to chime in on what is needed to make this possible.

1 Like
3

Those are definitely some interesting ideas. That said, not all of them are technically feasible, and a few rely on assumptions that overlook, or are simply unaware of, the inherent limitations and security constraints of the underlying stack.

In theory, yes, LuCI could be extended to support multi-host awareness. But there’s good reasons why none of the existing multi-device management tools are implemented as pure web applications. Achieving that in LuCI would require a significant architectural overhaul, far beyond a simple extension.

2 Likes
4

NB: This is the "feature request" forum, and the OP made a feature request about LuCI. I'm genuinely unsure what you're trying to achieve by asking them for their wireless configuration.

5

takimata,

Thank you so much for your reply :grinning_face:
I realize its a broad post, and I do apologize to some degree for that.
I didn't think less info would have been very clear however.

Which items are not technically feasible vs security concerns?

Does that statement apply to running Luci locally or just multi device management?

6

ubus is inherently a local IPC mechanism, it isn't designed for remote access or multiplexing. Sure you could tunnel it out via SSH, but then you would have to deal with the fact that browsers don't natively support SSH. And you'd also have to build a security abstraction around all of this, to give you concurrency control, multi-client authentication, and security boundaries.

You can't run LuCI locally.

7

This JS html5 ssh client does exactly that, so its doable.

There are others but too many rely on node.js or worse

What is the main reason(s) it "can't" run locally?

8

No, it doesn't, it expects a websocket proxy. Browsers don't do raw TCP. It is, however, possible to create an SSH client in WASM, to which I would wish you good luck and have fun.

In its current form? Mainly CORS and session-based authentication.

9

Ah missed that, thank you.

Apparently WASM SSH is already accomplished tho

10

If Luci was client side webserver hosted, what type of data connector would you suggest on the device?

11

LuCI is using JSON-RPC via XHR, this could also work across devices (with proper CORS permissions). The problem is not the "data connector". The challenge is auth, you would have to log into each device individually or create some sort of authorization framework. And then, of course, you would look at refactoring the entirety of LuCI to be multi-device aware, which is probably the point of the whole exercise.

1 Like
12

Luci is designed to manage a single device.

Manging multiple devices is easier said than done. It's a lot of work.
Commercial solutions either sell for a lot of money or are designed for 1 specific hardware brand and are geared towards vendor lock-in.

But hey, feel free to get started yet another solution for this.

Cucumberwifi is dead BTW, the main website is up but if you try to signup/signin you'll see it doesn't work, the real service has been discontinued.

Most solutions die after some time because it's hard to sustain these efforts, it's very ungrateful work: users ignore the complexity of building a solution that can work with countless different types of hardwares and infinite potential configurations, few are willing to contribute and help with maintenance and many are quick to complain, cry on forums and even disrespect the maintainers publicly when things don't work out for them, so maintainers get tired and leave for happier shores.

1 Like
13

Valid points all...

I don't think logging into 1 device at a time is a deal breaker.

It may not be multi device in one session, but a new Luci app or module could keep track of login credentials, configs/backups per device or device classes, and still greatly simplify multiple device management.

Multi device per session aside, we would still gain many other benefits listed in the op. :smiley:

This is SOOO true. It's actually one of the biggest reasons IMHO to use luci as the base framework, and add apps/modules to extend utility towards multi device management, even if its not mutli-per-login-session.

Its mainly about consistency, while extending an already mature framework in active development, with a large app/module contributor base.

As mentioned in the op...

14

I was not implying that this would be a replacement for OpenWisp,
or commercial enterprise targeted solutions. I'm grateful you and many others love OpenWRT enough to work around current limitations.

Most Enterprise users, however, would never even consider using low(er) end hardware or non commercial distros.
They live in the glibc - systemd - PHP+python+perl+too many to mention here, dependencies world. They want 24-7 live support, local techs on call, and industry wide statistically proven and insured speed and uptime.

As far as "yet another separate project" with similar interests...
That is something I feel we should avoid like the plague in this case.
I'm with Torvalds on that one...
The frustrations of fragmentation in userspace is already off the rails.

Android is a prime example of unification vs where-is as-is.
As awful & egregious as their userspace and eco system is, even against their own users, they have proven that tighter controls, with focused optimizations and adding functionality over time, make for rapid progress.
https://stats.areppim.com/stats/stats_mobiosxtime.htm

15
  • Does this suggestion imply that one must download the entire software repository (for all targets) to the local machine?
  • Perhaps I misunderstood the sentence structure - but where is this proxied Internet coming from (i.e., does this device used for provisioning need multiple Network Interfaces to be usable for this purpose)? :wink:
  • Single tunnel - to multiple devices?
  • BTW - modern LuCI uses HTTPS
  • Another user already noted the lack of SSH in browsers

Tunneling where (if no network connection)?

So (like inquiry above) - how are copies of the repo obtained?

1 Like
16

No, it just highlights that having Luci running on the controller host opens doors to more easily adding/linking local or custom content into an already established interface/UI.

The controlling host machine will almost always have internet access by the nature or convenience of its normal useage.
That presents the option to proxy that connection to the device thru the browser.

and https://gist.github.com/longbill/d321fc371e6dda9acf40decdb923c048

Implementing similar methods as a Luci module/app would be the preferred end result.

Yes, takimata was kind enough to correct me on the lack of raw TCP in browsers. The tunnel would need to be JSON-RPC and https compliant.
Maybe we could start with using device side uhttpd as the tunnel mechanism for now?

Tunnel between device and host machine. (already needed connection to access device side Luci currently)

Or roll your own repo...

17

Correct.

So what occurs when you have to use that "normal" connection to access the device you wish to configure (which you admit, has no Internet)?

With the "normal" connection - prior to usage, correct?

Also, is this controller running OpenWrt or some other OS?

18

@takimata
Could we start out by using uhttpd as a tunneling endpoint on the device in some way?

19

There are many scenarios to network and internet topology, not sure which type you are referring to.

If you want local repos, of course they need to be on the host machine 1st.

The host Luci could run on any OS with a compliant mini webserver and browser available. That should mean Linux, Windows, Macos, and Android to start.
Of course that could also mean "one openwrt device to rule them all" :wink:

20

I like the idea, and thought I would add my 2c to the discussion.

This is similar to the Mikrotik approach of keeping the configuration for all devices on the router, and the clients request their configuration from the master. Google "CAPSMAN Master Slave" for details, which I am truthfully unfamiliar with.

One detail is that this is really only aimed at configuring multiple Wireless Access Points, and not arbitrary OpenWrt config. That might be enough for some purposes.

However, one detail to keep in mind is that due to the vast OpenWrt ecosystem, there are all sorts of wireless interfaces that can be configured. You could also have the main device on one architecture, and various AP devices on a variety of different architectures/platforms, all of which adds to the complexity.

I think that there would be a few technical things to sort out. There's absolutely nothing to prevent an AP from querying uci via JSON-RPC queries to the HTTP server, using the existing HTTP support in the image (wget/curl, etc). That said, there are a few obstacles to clear first.

  1. Adoption/authentication/encryption. This is something that would need to be baked in, but it is not a simple problem to solve. I'd suggest that there is no way that this could be baked into the default build (and be running by default). It would need to be a custom firmware build. Not to say that the creds/keys would be baked into the firmware, just that you cannot have everyone's openwrt installations vulnerable to "slaving" to another OpenWrt device, just because it completed a handshake procedure.
  2. I envision a "main" OpenWrt device broadcasting some sort of announcement of its presence to its local network. mDNS or something along those lines. It could also potentially include a custom DHCP option when handing out addresses to new devices, perhaps?
  3. new "AP" devices (perhaps only during firstboot, which might work around the problems in 1.) observe the announcements, connect to the main device, and follow some sort of enrolment procedure. This may need approval in the main device to prevent leaks of secrets like passphrases, etc.
  4. The enrolment process exchanges keys, so each party can authenticate each other, and encrypt between them. I'm not sure this should be http-based, as it would involve X.509 certificates. Perhaps something ssh-based would be better? Ideally with ssh forced commands, or something along those lines, if dropbear supports them.
  5. The enrolment process also sets up permissions for what RPC functions the AP can perform.
  6. UCI would then need to be updated to handle network configuration of the AP's, in particular, things like VLAN's for wired networks, as well as WiFi configuration. AP devices would be responsible for informing the main device what interfaces it has, and their capabiltiies, while the main device would be responsible for allocating each AP's wireless interface to a SSID, and linking that to a wired interface/VLAN. This would be for things like guest/IOT networks, etc.

Just those few points above are complicated enough, and quite possibly will only be used by a very few users, probably those that are already quite capable of managing the devices independently anyway.

Dunno if useful, but perhaps it moves the discussion from "running luci on the device" (no OpenWrt device is going to have the resources to run a headless browser, Javascript and all) to plausible ways of actually achieving the desired end result. A lot of work, though!