3 ms·

OpenWISP states in its docs that you should be running at least 20 devices to make it worth it. [1] So it's not supposed to be a easy way to manage a few device

by foepys 1y ago

OpenWISP states in its docs that you should be running at least 20 devices to make it worth it. [1] So it's not supposed to be a easy way to manage a few devices for home users. > However, OpenWISP may not be the best fit for very small networks (fewer than 20 devices), organizations lacking IT expertise, or enterprises seeking open-source alternatives solely for cost-saving purposes. 1: https://openwisp.org/faq/#suitable https://openwisp.org/faq/#suitable

CursedSilicon 1y ago
I saw that. Admittedly I'm only interested in a few of its functions. Namely roaming and guest hotspots I could wire up all of that manually. But I'm excited for the chance to learn something new
rubenbe 1y ago
It's for exactly that reason I started with OpenSOHO. It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit). https://github.com/rubenbe/opensoho https://github.com/rubenbe/opensoho It is still a work in progress, but it is easy to deploy (one golang binary based on pocketbase)
- CursedSilicon 1y ago
  This looks a lot closer to what I'm after. Bookmarked the git repo :)
- pseudosavant 1y ago
  Very interesting project! I was thinking of something that would fill this gap. Based on your experience, as OpenSOHO seems to use OpenWISP, what do you wish you knew about OpenWISP before you started this?
  - rubenbe 1y ago
    Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well. The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end) The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan". The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.
    - pseudosavant 1y ago
      I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push. On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua. I think I'm going to have an agent start coding this up today and see where it gets.
      - rubenbe 1y ago
        Nice idea! I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller. I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not. An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)

by foepys 1y ago

CursedSilicon 1y ago

I saw that. Admittedly I'm only interested in a few of its functions. Namely roaming and guest hotspots I could wire up all of that manually. But I'm excited for the chance to learn something new

rubenbe 1y ago

It's for exactly that reason I started with OpenSOHO. It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit). https://github.com/rubenbe/opensoho https://github.com/rubenbe/opensoho It is still a work in progress, but it is easy to deploy (one golang binary based on pocketbase)

CursedSilicon 1y ago
This looks a lot closer to what I'm after. Bookmarked the git repo :)
pseudosavant 1y ago
Very interesting project! I was thinking of something that would fill this gap. Based on your experience, as OpenSOHO seems to use OpenWISP, what do you wish you knew about OpenWISP before you started this?
- rubenbe 1y ago
  Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well. The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end) The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan". The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.
  - pseudosavant 1y ago
    I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push. On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua. I think I'm going to have an agent start coding this up today and see where it gets.
    - rubenbe 1y ago
      Nice idea! I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller. I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not. An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)