As per title, I'm considering building an open source network controller to make it easier to manage and monitor multiple OpenWrt devices in a deployment, and I'm looking for feedback to try and gauge interest to see if something like this would be useful for the community.
I'm considering building a controller kind of like the Unifi Network Controller, initially it would be a very basic interface to make provisioning configuration and managing firmware updates easier, but over time it could include monitoring and stats etc to help with troubleshooting and debugging etc.
I'm aware of OpenWISP, but I'm looking to make something far more simple and easy to use, and possibly more opinionated and structured to make it easier and more effective to use for the average user.
I've already built a CLI tool that can quickly and easily provision configuration onto multiple OpenWrt devices (https://github.com/jasrusable/openwrt-configurator), and I'm now wanting to evaluate extending this with a web UI.
Would something like this be useful or interesting to you?
That's the elephant in the room with OpenWISP, isn't it?
I've thought occasionally about doing something like your CLI code, but never got past the "thinking about it" stage, so
I just took a glance over the CLI code and didn't see anything that would scan an existing device and extract a starting point config for it. Did I miss something? Seems like a little on-device ucode utility would be pretty straightforward.
I've started on a similar idea.
The idea is to leverage the OpenWISP daemons on the OpenWRT routers, but have a simple to deploy backend.
Big warning! This is early software, the feature set is limited. But you can use it to monitor the connected wifi clients and deploy wifi access points (but no support yet to make them end up on different VLANs)
I made quick screenshot, even if at this moment it is mostly stock PocketBase.
Pocketbase is what allows easy deployment (and development) which is key for me. OpenWISP is complex to set up, because it can scale so well to thousands of devices. By adding a soft limit on the number of devices, the software can be simpler. My vision is to try to centralise the typical setup that a SOHO user wants. A few SSIDs on a handful of access points/routers. Maybe I want to support simple VLAN setups (but nothing complex, that should be done in Luci on the main router, OpenSOHO should help to configure the VLAN number on all the access points in that case. By limiting the flexibility and feature set I hope it to be easier to use (easier than the flexible OpenWISP templates) and limited in scope (since complex setups need to be configured in Luci, but generally only on the main router. If your setup doesn't fit this description (1 router plus a handful of switches and APs), then probably OpenSOHO is not for you
Extra features I want to have: good monitoring (already partially there) and settings that would require a user to log in on all APs to change a setting manually. e.g. rotating a guest WIFI password.
I've also started adding Home Assistant compatible REST APIs, since me and probably quite some others have a Home Assistant setup.
I'm also working on a management project or sorts. Like you I started with trying to make a dedicated controller but I've moved on to building a gossip based system that is scripting focused.
One of the things I really I think would be useful is a way for one OpenWRT device to control and configure a different device. The idea would be that you would have one Luci page for a group of devices that you could use to mass configure something like a group of access points. This same system should be able to set any UCI value as one of my complains with OpenWISP is that it significantly limits the flexibility of OpenWRT.
I think the more you work on a control system for OpenWRT the more you will realize it isn't easy to do. I would focus on using UDP and dTLS for communication since TCP and TLS add a lot of overhead.
That's a different and interesting approach. I see that you also want to keep Luci central in the configuration setup. I fully agree with you that the configuration/problem space is way bigger than you would think at first sight, that's the reason I want to keep the supported configuration scope really limited. Also, please do share the git repo when it's usable
I like it. Something like OpenWisp-in-a-Box would be nice.
There was a similar effort for a simple Unifi Controller where someone mentioned they had a custom controller running with Unifi APs, Mikrotik Switches and I forgot about the routers. And that it wasn't that hard to do for opinionated network setups. They wanted to consider open sourcing, but I can't find these comments anymore. Maybe deleted as it didn't happen.
I have such a controller on "the list", too.
Looking for a bunch of VLANs with their own SSID, all dumb APs with the same configuration, client ports with one VLAN on switches and link aggregation between switches. Everything else without special support. There are simply to many options.
I see the go effort in the other comment, in principle that can run on a router running Openwrt. For metrics collection or firmware caching some kind of storage that can handle regular writes would be nice. But the basic configuration distribution works even without that. So you could bootstrap networks by configuring an OpenWRT router, add the controller and its luci package, then provision the rest of the network from there more or less automatically.
The only thing I missed in this thread is something like the Unifi discovery process where new devices search their controller via local DNS, DHCP option and offer themselves for adoption. But that's missing from OpenWISP, too. (you have to set endpoint and secret ahead of time)
Thanks! yes a docker container should be possible. I'll add one later when the software is a bit more complete. Golang allows easy cross compilation which is a plus given the diverse CPU landscape supported by OpenWRT. Howver, you will need an OpenWRT device with a bit of memory, since golang is statically compiled (so bigger than all the nicely memory optimized packages that OpenWRT provides)
