At Newport Wireless Mesh, we are considering migrating directly to OpenWISP. We have more than one volunteer who works with IAC-based systems and want to make sure our contributions help advance the project.
I’m less interested in supported devices, as ultimately OpenWrt support and OpenWISP node support come hand-in-hand.
On the other hand, I’m more interested (and wish there had been an option) in discussing the work to be done to keep OpenWISP’s firmware distribution as close as possible to mainline OpenWrt. Excerpts from an internal email:
Hey Diane,
OpenWISP is definitely FOSS.
I’ve done a bit of research here in the past, it’s definitely something we should consider:
setup is intentionally Ansible-driven
it provides a fairly complete management pane
Automatic cert management, if you need certs!
My “feeling” on the downside is that it’s always seemed like a walled garden – e.g. using NetJSON to ship […] network configuration. [I want to push for more of OpenWISP to use mainline OpenWrt, as its] base system now has a huge amount of common functionality that would enable high performance while also supporting the hardware we use:
Wireguard / unetd rather than OpenVPN (which will seriously suffer on the AR7161 CPUs we have): New WireGuard based OpenWrt VPN implementation: unetd - For Developers - OpenWrt Forum
Reimplementing the NetJSON configuration parsers (e.g. netjsonconfig/netjsonconfig/backends/openwrt/converters at master · openwisp/netjsonconfig · GitHub) on the client-side using ucode (which has native uci and ubus bindings): GitHub - jow-/ucode: JavaScript-like language with optional templating
Ditto for the monitoring code, all currently in lua + shell: GitHub - openwisp/openwisp-config: OpenWRT configuration agent for OpenWISP Controller
Using the well-community-supported prometheus data backend in place of the Influxdb one (though not sure if the architecture supports it, InfluxDB is push rather than pull): openwisp-monitoring/openwisp_monitoring/db/backends at master · openwisp/openwisp-monitoring · GitHub
Basically, I’m noting that this project makes a lot of its own choices; some are very much in common with [what we use in OpenWrt], some are not. It’d be nice, though not necessary, to help reconcile those differences in choices.
Just my pipe-dream. I am VERY interested in listening to @nemesis about their project, because we are VERY interested in moving to OpenWISP. Only once we’ve deployed OpenWISP can we really contribute :^)