OpenSOHO, an OpenWISP alternative for small networks

I’ve been working on OpenSOHO, as a simpler alternative to OpenWisp to configure multiple openwrt devices.
It is easy to deploy (one golang binary) and opinionated in the setups it supports.

It is built to configure and monitor a small number OpenWRT based network devices. Hence the name SOHO from Small Office Home Office (SOHO) Networks. Only OpenWRT 24.10.x DSA is tested.

  • From 2 to 20 devices

  • Compatible with openwisp-config and openwisp-monitoring.

It is inspired by OpenWisp, but aims for networks which are too small to be maintained with OpenWISP. As OpenWisp mentioned:

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.

To keep this project relatively small (and manageable). I chose to reuse the openwisp daemons on the APs and routers. The controller itself is fairly big (since it is a statically linked binary) so that should run on a PC style machine or a beefy OpenWRT device.

Getting started

Non goals

  • Support complex setups: crazy firewall setups will remain a thing to be done in Luci
  • Scalability: if you have 100+ APs, the original OpenWisp is perfect for that
  • Lightweight: I don’t have the time to write highly optimized low-memory C-code. I prefer to focus on features with the time I have available.

Issue reporting

  • If you have issues, please report them as a bug (or immediately as a PR :wink: )
13 Likes

Latest release

Great! At the moment I’m creating new builds for my dumb AP’s. I created shell scripts about 4 years ago that run uci commands. As I mentioned in another topic I have to admit I’m experiencing configuration drifts between my dumb AP’s themselves and the shell script. For that reason this project seems interesting to me.

I’ve got one dumb AP on the attic, it isn’t used heavily by clients so this will serve as my guinea pig. Backup is already in place.

From what I’ve seen the past few days, is that I’m not sure how I can see or force the set-up in monitoring mode only, since my ssh keys were gone on the dumb AP’s I added to OpenSOHO.

How would you like to receive feedback? Primarily via this topic? Issues via Github? PR’s via Github?

I’ve got a request for instance; I’d like to setup an SMTP server with OpenSOHO. I have one on my local network but it’s very simple without TLS or authentication. OpenSOHO expects TLS and authentication AFAIK. Is it possible to add an SMTP server that doesn’t have TLS and authentication?

Issues are best via reported via github, that makes it easier to keep track of them.

  • SMTP: that’s functionality provided by pocketbase, I can have a look whether I can water down its security requirements for the OpenSOHO case
  • You can disable a device which will make OpenSOHO not update the config. BUT in v0.5.1, they are still enabled by default. I’ll add a flag to change this default behavior.
  • SSH keys: dropbear doesn’t support authorized_keys.d/* style so unfortunately OpenSOHO cannot merge it with existing keys (the OpenWisp daemon does this for UCI configuration files). Although I do consider it a bug that it overwrites the /etc/dropbear/authorized_keys file when no keys are configured. Will fix.

Allright, I’ve just started version 0.5.1 and trying some settings in OpenSOHO. It’s the first time I’m actually trying that. My first impression is that it is not very intuitive. I have:

  • added one OpenWRT device
  • created a vlan, just a name, I expected to enter a number to besides a name. The Id is probably a pocketbase Id.
  • I created a Wifi network with SSID and so on and linked that to the vlan I created.
  • Then, for some reason I don’t quite follow I created a radio that I had to “pick” from the OpenWRT-device. I needed to give it a number, select a band and I must choose a frequency. There’s no “auto” frequency option. A mac_address is optional.
  • Then I created an interface, selected the OpenWRT-device, selected the Wifi network I created earlier. I had to choose the band, which is what I thought I did in the radio section. I also must enter mac_address. I assume this is the BSSID mac_address of the one of the radio’s of the OpenWRT device? At last I entered a random name for the interface.

I guess this is what I needed to do to get the first config pushed. But then I run into:

Sun Aug 24 17:23:59 2025 daemon.err root: Data not sent successfully. Response code is "301". Error message is ""
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: root: Data not sent successfully. Response code is "301". Error message is ""
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: > POST //api/v1/monitoring/device/6264fcd4-9f48-4acb-9df1-280e053a7e2d/?key=f1f1e739d44137017da1b9a3e38cfd7d&time=24-08-2025_14:59:40.000000 HTTP/1.1
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: > Host: 192.168.1.254:8090
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: > User-Agent: curl/8.12.1
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: > Accept: */*
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: > Content-Type: application/json
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: > Content-Length: 8726
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: >
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: } [8726 bytes data]
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: < HTTP/1.1 301 Moved Permanently
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: < Location: /api/v1/monitoring/device/6264fcd4-9f48-4acb-9df1-280e053a7e2d/?key=f1f1e739d44137017da1b9a3e38cfd7d&time=24-08-2025_14:59:40.000000
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: < Date: Sun, 24 Aug 2025 15:23:59 GMT
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: < Content-Length: 0
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: <
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: tr: write error: Broken pipe
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: head: standard output: I/O error
Sun Aug 24 17:23:59 2025 daemon.warn root: Data not sent successfully. Retrying in 7 seconds.
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25571]: root: Data not sent successfully. Retrying in 7 seconds.
Sun Aug 24 17:23:59 2025 daemon.info root: Collecting NetJSON Monitoring data.
Sun Aug 24 17:23:59 2025 daemon.err openwisp-monitoring[25570]: root: Collecting NetJSON Monitoring data.

I could report an issue via GitHub. But I’m holding back a bit. When I question myself why I do that I must admit that I don’t find the experience intuitive and think I need to tinker with vlans and bridges and multiple SSID’s on the command line or webinterface to get it all to work together. That’s holding me back a bit. The other thing is the api telling me with the http 301 error that somethings changed. I’m not sure what to make of that.

I like the concept and try to help but it’s a hobby too.

I’m aware the onboarding process is not amazing yet.

  • added one OpenWRT device

  • created a vlan, just a name, I expected to enter a number to besides a name. The Id is probably a pocketbase Id.
    Indeed, there is no full support for VLANs yet, I’m doing something wrong on my setup which I need to fix first. But VLAN support, with the ID will be there at some point (that’s one of the main reasons I started this project)

  • I created a Wifi network with SSID and so on and linked that to the vlan I created.

    • Good
  • Then, for some reason I don’t quite follow I created a radio that I had to “pick” from the OpenWRT-device. I needed to give it a number, select a band and I must choose a frequency. There’s no “auto” frequency option. A mac_address is optional.

    • This should normally not necessary. It is sufficient to select the Wifi from the Device section.
    • The radio data should be autogenerated from the monitoring data.
    • There is indeed no “auto” frequency options since the OpenWisp daemon always reports the actual frequency used. I’ll have a look to add it in the future.
  • Then I created an interface, selected the OpenWRT-device, selected the Wifi network I created earlier. I had to choose the band, which is what I thought I did in the radio section. I also must enter mac_address. I assume this is the BSSID mac_address of the one of the radio’s of the OpenWRT device? At last I entered a random name for the interface.

    • This should also be autogenerated too from the monitoring data. But since the monitoring doesn’t work that’s tricky

Thanks for all the feedback, it is clear I should make some fields read-only to make things clearer (maybe also hide some of these tables since they could be considered internal)

With regard to the 301 “error” in the monitoring data. Could you have a look in the logging of OpenSOHO itself? it is currently VERY chatty on purpose. So the 301 might be a bug, I haven’t seen it before. Maybe also have look with TCPdump on the AP to check what’s being sent:

tcpdump -n -i br-lan -vvv port 8090 -A

Also you might want to check whether this command outputs valid json on the AP:
netjson-monitoring --dump "*"

It is indeed a hobby, that’s why I made the scope a bit limited. If not it could become a fulltime job :smiley:

2 Likes

I had started OpenSOHO with the -dev option and indeed quite chatty. I don’t see anything weird in that output. I see the config of thewifi-iface's with the network, vlan and SSID being logged and lots of SQL commands but no errors on that part.

When I enter netjson-monitoring --dump "*" I see a lot of json, a small example:

{"type":"DeviceMonitoring","general":{"local_time":1756061762,"uptime":99912,"hostname":"ap-attic"},"interfaces":[{"Mac": and so on.

I see that this json output does carry a lot of monitoring information. I ran the output through a JSON-validator and it says that it’s valid JSON-output.

Here’s some output from tcpdump, I can’t make much of it, except that sometimes I see that a cksum is incorrect. But that might also be the result of the http/301 error:

j....6                                                                                                                
19:09:21.849272 IP (tos 0x0, ttl 64, id 36080, offset 0, flags [DF], proto TCP (6), length 52)                                                                                                                                              
    192.168.1.254.8090 > 192.168.1.250.34874: Flags [.], cksum 0xa5a6 (correct), seq 1, ack 8996, win 454, options [nop,nop,TS val 2987027199 ecr 45909046], length 0
E..4..@.@.(............:.,..H.0C...........
. 
j....6
19:09:21.849463 IP (tos 0x2,ECT(0), ttl 64, id 36081, offset 0, flags [DF], proto TCP (6), length 286)
    192.168.1.254.8090 > 192.168.1.250.34874: Flags [P.], cksum 0xc08d (correct), seq 1:235, ack 8996, win 501, options [nop,nop,TS val 2987027199 ecr 45909046], length 234
E.....@.@.'............:.,..H.0C...........
.
j....6HTTP/1.1 301 Moved Permanently
Location: /api/v1/monitoring/device/6264fcd4-9f48-4acb-9df1-280e053a7e2d/?key=f1f1e739d44137017da1b9a3e38cfd7d&time=24-08-2025_14:59:40.000000
Date: Sun, 24 Aug 2025 17:09:21 GMT
Content-Length: 0


19:09:21.849508 IP (tos 0x0, ttl 64, id 39802, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.250.34874 > 192.168.1.254.8090: Flags [.], cksum 0x856f (incorrect -> 0xa642), seq 8996, ack 235, win 63, options [nop,nop,TS val 45909047 ecr 2987027199], length 0
E..4.z@.@............:..H.0C.,.....?.o.....
...7.
j.
19:09:21.850682 IP (tos 0x0, ttl 64, id 39803, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.250.34874 > 192.168.1.254.8090: Flags [F.], cksum 0x856f (incorrect -> 0xa640), seq 8996, ack 235, win 63, options [nop,nop,TS val 45909048 ecr 2987027199], length 0
E..4.{@.@............:..H.0C.,.....?.o.....
...8.
j.
19:09:21.851621 IP (tos 0x0, ttl 64, id 36082, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.254.8090 > 192.168.1.250.34874: Flags [F.], cksum 0xa487 (correct), seq 235, ack 8997, win 501, options [nop,nop,TS val 2987027201 ecr 45909048], length 0
E..4..@.@.(............:.,..H.0D...........
.

About the hobby part, you got a lot further than I ever did. I had many idea’s but mostly it ended up in the back of my mind and stayed there. Kudo’s for sharing this project.

– EDIT –

I just had a look after dinner. I can see the newly created Wifi networks by OpenSOHO on guinea pig OpenWRT device. There’s a third radio device that has been added. Radio0 and radio1 are indeed in this device. Radio2 is new. I guess I messed that up. So it seems to work that what I configure in OpenSOHO is created in OpenWRT. I haven’t found a clue as to where the http/301 is referring to.

The TCPdump is not super useful since it’s too short.
Could you have a look for a POST request above this 301 redirect?

The request should look like:

E..|H!@.@..9
...
.......L.$w........1......
)...p.H.POST /api/v1/monitoring/device/a0ce2acb-c34b-421e-bbbb-aaaaaaaaaaa/?key=00000000000000001111111122222222&time=24-08-2025_17:37:50.000000&current=true HTTP/1.1
Host: 192.168.1.254:8090
User-Agent: curl/8.12.1
Accept: /
Content-Type: application/json
Content-Length: 17647

It is really weird, since nowhere in the OpenSOHO code, there is an explicit 301. The only thing I can think of is that the POST URL is indeed an unexpected one and Pocketbase does a redirect.

With regard to the hobby thing, I’ve chosen my software stack for productivity in the few available, I don’t want to have to create another CRUD framework, pocketbase does that very well :smiley:

2 Likes

Got a POST:

19:53:31.643448 IP (tos 0x0, ttl 64, id 39155, offset 0, flags [DF], proto TCP (6), length 52)                                                                                                                                              
    192.168.1.250.40878 > 192.168.1.254.8090: Flags [.], cksum 0x856f (incorrect -> 0x31ba), seq 8996, ack 235, win 63, options [nop,nop,TS val 48558841 ecr 2989676993], length 0                                                          
E..4..@.@....................J$b...?.o.....                                                                                                                                                                                                 
.....2..                                                                                                                                                                                                                                    
19:53:31.644002 IP (tos 0x0, ttl 64, id 39156, offset 0, flags [DF], proto TCP (6), length 52)                                                                                                                                              
    192.168.1.250.40878 > 192.168.1.254.8090: Flags [F.], cksum 0x856f (incorrect -> 0x31b8), seq 8996, ack 235, win 63, options [nop,nop,TS val 48558842 ecr 2989676993], length 0                                                         
E..4..@.@....................J$b...?.o.....                                                                                                                                                                                                 
.....2..                                                                                                                                                                                                                                    
19:53:31.645741 IP (tos 0x0, ttl 64, id 46660, offset 0, flags [DF], proto TCP (6), length 52)                                                                                                                                              
    192.168.1.254.8090 > 192.168.1.250.40878: Flags [F.], cksum 0x2fff (correct), seq 235, ack 8997, win 501, options [nop,nop,TS val 2989676995 ecr 48558842], length 0                                                                    
E..4.D@.@..6.............J$b......../......                                                                                                                                                                                                 
.2......                                                                                                                                                                                                                                    
19:53:31.645799 IP (tos 0x0, ttl 64, id 39157, offset 0, flags [DF], proto TCP (6), length 52)                                                                                                                                              
    192.168.1.250.40878 > 192.168.1.254.8090: Flags [.], cksum 0x856f (incorrect -> 0x31b4), seq 8997, ack 236, win 63, options [nop,nop,TS val 48558843 ecr 2989676995], length 0                                                          
E..4..@.@....................J$c...?.o.....                                                                                                                                                                                                 
.....2..                                                                                                                                                                                                                                    
19:53:34.668056 IP (tos 0x0, ttl 64, id 773, offset 0, flags [DF], proto TCP (6), length 60)                                                                                                                                                
    192.168.1.250.53180 > 192.168.1.254.8090: Flags [SEW], cksum 0x8577 (incorrect -> 0xb692), seq 636450549, win 32120, options [mss 1460,sackOK,TS val 48561866 ecr 0,nop,wscale 9], length 0                                             
E..<..@.@..n............%.v.......}x.w.........                                                                                                                                                                                             
...........                                                                                                                                                                                                                                 
19:53:34.669877 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)                                                                                                                                                  
    192.168.1.254.8090 > 192.168.1.250.53180: Flags [S.E], cksum 0x0719 (correct), seq 1554922085, ack 636450550, win 65160, options [mss 1460,sackOK,TS val 2989680019 ecr 48561866,nop,wscale 7], length 0                                
E..<..@.@..s............\.:e%.v..R.............                                                                                                                                                                                             
.2..........                                                                                                                                                                                                                                
19:53:34.669945 IP (tos 0x0, ttl 64, id 774, offset 0, flags [DF], proto TCP (6), length 52)                                                                                                                                                
    192.168.1.250.53180 > 192.168.1.254.8090: Flags [.], cksum 0x856f (incorrect -> 0x346d), seq 1, ack 1, win 63, options [nop,nop,TS val 48561868 ecr 2989680019], length 0                                                               
E..4..@.@..u............%.v.\.:f...?.o.....                                                                                                                                                                                                 
.....2..                                                                                                                                                                                                                                    
19:53:34.670162 IP (tos 0x2,ECT(0), ttl 64, id 775, offset 0, flags [DF], proto TCP (6), length 7292)                                                                                                                                       
    192.168.1.250.53180 > 192.168.1.254.8090: Flags [P.], cksum 0xa1b7 (incorrect -> 0x734e), seq 1:7241, ack 1, win 63, options [nop,nop,TS val 48561868 ecr 2989680019], length 7240                                                      
E..|..@.@..*............%.v.\.:f...?.......                                                                                                                                                                                                 
.....2..POST //api/v1/monitoring/device/6264fcd4-9f48-4acb-9df1-280e053a7e2d/?key=f1f1e739d44137017da1b9a3e38cfd7d&time=24-08-2025_14:59:40.000000 HTTP/1.1                                                                                 
Host: 192.168.1.254:8090                                                                                                                                                                                                                    
User-Agent: curl/8.12.1                                                                                                                                                                                                                     
Accept: */*                                                                                                                                                                                                                                 
Content-Type: application/json                                                                                                                                                                                                              
Content-Length: 8726                                                                                                                                                                                                                        
                                                                                                                                                                                                                                            
{"type":"DeviceMonitoring","general":{"local_time":1756054779,"uptime":92929,"hostname":"ap-attic"},"interfaces":[{"mac":
<snip lots of JSON>
":0,"tx_window_errors":0,"tx_bytes":1885753091,"collisions":0,"rx_bytes":1303184020,"rx_fifo_errors":0,"rx_dropped":1,"tx_fifo_errors":0,"rx_compressed":0,"multicast":0,"tx_compressed":0,"rx_missed_errors":0,"tx_dropped":0},"up":true,"s
peed":"1000F"}],"resources":{"memory":{"total":486522880,"shared":2859008,"free":302714880,"cached":63057920,"available":320610304,"buffered":53248},"cpus":2,"disk":[{"filesystem":"\/dev\/root","available_bytes":0,"mount_point":"\/rom",
"used_percent":100,"size_bytes":13631488,"used_bytes":13631488},{"filesystem":"\/dev\/mtdblock13","available_bytes":10289152,"m
19:53:34.670200 IP (tos 0x2,ECT(0), ttl 64, id 780, offset 0, flags [DF], proto TCP (6), length 1807)
    192.168.1.250.53180 > 192.168.1.254.8090: Flags [P.], cksum 0x8c4a (incorrect -> 0x5741), seq 7241:8996, ack 1, win 63, options [nop,nop,TS val 48561868 ecr 2989680019], length 1755
E.....@.@...............%..>\.:f...?.J.....
.....2..ount_point":"\/overlay","used_percent":19,"size_bytes":12713984,"used_bytes":2424832}],"load":[0.28,0.09,0.06],"swap":{"free":0,"total":0}},"dns_servers":["192.168.1.254"],"neighbors":[{"mac":"00:e2:69:59:1f:93","state":"REACHAB
LE","interface":"br-lan","ip":"192.168.1.254"},{"mac":"8c:3b:ad:2d:25:24","state":"REACHABLE","interface":"br-lan","ip":"192.168.1.252"},{"mac":"82:f6:6e:b4:0f:82","state":"STALE","interface":"br-lan","ip":"192.168.1.133"},{"mac":"b4:e6
:2d:79:d7:e8","state":"STALE","interface":"br-lan","ip":"192.168.1.53"},{"mac":"54:60:09:0b:ab:fe","state":"STALE","interface":"br-lan","ip":"192.168.1.33"},{"mac":"38:22:e2:2c:2b:d6","state":"REACHABLE","interface":"br-lan","ip":"192.1
68.1.2"},{"mac":"ec:b5:fa:08:51:88","state":"STALE","interface":"br-lan","ip":"192.168.1.40"},{"mac":"b4:e6:2d:7a:e6:df","state":"STALE","interface":"br-lan","ip":"192.168.1.51"},{"mac":"94:e3:6d:98:0d:8a","state":"STALE","interface":"b
r-lan","ip":"192.168.1.31"},{"mac":"02:42:c0:a8:01:d9","state":"STALE","interface":"br-lan","ip":"192.168.1.217"},{"mac":"84:f3:eb:e6:7b:86","state":"STALE","interface":"br-lan","ip":"192.168.1.54"},{"mac":"dc:ef:09:f2:76:00","state":"R
EACHABLE","interface":"br-lan","ip":"192.168.1.253"},{"mac":"4c:11:ae:04:17:ec","state":"STALE","interface":"br-lan","ip":"192.168.1.52"},{"mac":"b0:7f:b9:f8:23:ae","state":"REACHABLE","interface":"br-lan","ip":"192.168.1.251"},{"mac":"
18:65:71:e5:fb:15","state":"STALE","interface":"br-lan","ip":"192.168.1.12"},{"mac":"00:a0:de:d4:c8:89","state":"STALE","interface":"br-lan","ip":"192.168.1.30"},{"mac":"02:42:c0:a8:01:d1","state":"STALE","interface":"br-lan","ip":"192.
168.1.209"},{"mac":"b8:4d:43:c2:23:7c","state":"STALE","interface":"br-iot","ip":"fe80::ba4d:43ff:fec2:237c"}]}
19:53:34.671054 IP (tos 0x0, ttl 64, id 29821, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.254.8090 > 192.168.1.250.53180: Flags [.], cksum 0x1c2f (correct), seq 1, ack 5793, win 475, options [nop,nop,TS val 2989680021 ecr 48561868], length 0
E..4t}@.@.@.............\.:f%......../.....
.2......
19:53:34.672239 IP (tos 0x0, ttl 64, id 29822, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.254.8090 > 192.168.1.250.53180: Flags [.], cksum 0x168f (correct), seq 1, ack 7241, win 467, options [nop,nop,TS val 2989680021 ecr 48561868], length 0
E..4t~@.@.@.............\.:f%..>...........
.2......
19:53:34.672269 IP (tos 0x0, ttl 64, id 29823, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.254.8090 > 192.168.1.250.53180: Flags [.], cksum 0x0fc1 (correct), seq 1, ack 8996, win 454, options [nop,nop,TS val 2989680021 ecr 48561868], length 0
E..4t.@.@.@.............\.:f%..............
.2......
19:53:34.672298 IP (tos 0x2,ECT(0), ttl 64, id 29824, offset 0, flags [DF], proto TCP (6), length 286)
    192.168.1.254.8090 > 192.168.1.250.53180: Flags [P.], cksum 0x22ac (correct), seq 1:235, ack 8996, win 501, options [nop,nop,TS val 2989680022 ecr 48561868], length 234
E...t.@.@.@.............\.:f%......."......
.2......HTTP/1.1 301 Moved Permanently
Location: /api/v1/monitoring/device/6264fcd4-9f48-4acb-9df1-280e053a7e2d/?key=f1f1e739d44137017da1b9a3e38cfd7d&time=24-08-2025_14:59:40.000000
Date: Sun, 24 Aug 2025 17:53:34 GMT
Content-Length: 0


I’m taking a guess here, but could the http/301 be caused by the length of the packet?

– EDIT –

It took me a bit of tinkering in OpenSOHO, but I managed to:

  • Create a Wifi network
  • Did not connect this Wifi network to a vlan, although one exists in OpenSOHO config.
  • Did not create a Radio interface
  • Did not create a Network interface
  • Only select the Wifi network (picker) in Devices for the guinea pig OpenWRT device (after setting the #numradios

And I’ve got an additional SSID, created and managed by OpenSOHO on both 2.4GHz and 5GHz radio’s with an identical setup! So in fact less to configure in OpenSOHO than I initially assumed.

What was unclear to me, is that OpenSOHO only touches Wifi, vlan, radio and interfaces that it creates. It doesn’t touch any other configuration that is already present on the OpenWRT device, which is good in my perspective, so I can’t soft brick myself out of the OpenWRT device (at least not via OpenSOHO).

1 Like

I do notice you have two slashes here //api, I only have /api. Does your server URL has a trailing slash? That might be the issue!
The size should not be an issue, I noticed the JSON on one of my routers is about 17Kbytes.

Yes indeed, that’s also largely thanks to the OpenWisp daemon that tries to do a clever merge. (Except for the ssh keys where that’s not possible)

Nice! :partying_face:

Indeed! That is the issue! I had this in my server URL in my /etc/config/openwisp :

http://192.168.1.254:8090/

After removing the trailing slash I see more information being populated in OpenSOHO. For instance the connected clients and the radios as well show up.

:clinking_beer_mugs:

3 Likes

is this podman and kubernetes based?

It is not containerized at this moment.
But it should be trivial to run it in podman (no need for kubernetes, since it only is one container)

I’ve created two “issues” as a request for enhancement. One is mentioned in this topic about SMTP. The other is to further expand wireless config options for roaming.

I’m considering adding another enhancement request but that is probably on your own private todo list as well and it’s likely tied to vlan’s: the option to add/manage interfaces that are connected to bridge devices. Those bridge devices are connected to a specific vlan. For instance:

two interfaces I added besides the default config interface lan:

config interface 'guest'
        option proto 'none'
        option device 'br-guest'

config interface 'iot'
        option proto 'none'
        option device 'br-iot'

And I added two bridge devices for these interfaces:

config device 'device_guest'
        option igmp_snooping '1'
        option name 'br-guest'
        list ports 'eth1.3'
        option type 'bridge'

config device 'device_iot'
        option igmp_snooping '1'
        option name 'br-iot'
        list ports 'eth1.5'
        option type 'bridge'

The reason why I’m hesitant to add this as a feature enhancement is that I’m still using swconfig instead of DSA. You probably have plans for vlan support in DSA. I’m guessing that vlan’s look different in DSA config than in swconfig. My current two additional vlan’s in swconfig look like this:

config switch_vlan 'switch0_vlan3'
        option description 'guest-network'
        option device 'switch0'
        option ports '1t 6t'
        option vid '3'
        option vlan '3'

config switch_vlan 'switch0_vlan5'
        option description 'iot-network'
        option device 'switch0'
        option ports '1t 6t'
        option vid '5'
        option vlan '5'

Having the three components (vlan, interface and bridge) together would allow me to tie the correct wireless network to the correct vlan via the interface and bridge. I’d guess that setting the option ports in the config switch_vlan ‘switch0_vlan3' section for instance could be challenging. But hey, if OpenWISP is able to do that, perhaps OpenSOHO can do that too. But perhaps you’re plans are different, so I thought I’d ask :innocent:

Indeed, I’m only planning to support DSA. I’m currently expanding the ethernet monitoring part to make sure that OpenSOHO has a good view on how the bridges of each device look like.

I might add a “raws snippets” section which allows to add unmanaged “config sections“ to config files (but not templated) so that could be a workaround if you really want to have a non-DSA config :wink:

Understood, I encourage you to focus on future proof functionality first. I don’t know if there is much difference for pocketbase and OpenWISP to configure DSA or swconfig with a simple flag for example, so I thought I’d just ask. As for swconfig vs DSA, I plan to replace my old but trusted R7800’s by newer devices sometime in the upcoming year or so. I’ll then go for a MediaTek-based chipset that should be fully supported by OpenWRT. I’d suggest not to spend too much time in supporting older versions. Personally, if it where my project I’d try to stick to managed config sections fully supported by OpenWISP. Who knows, if you’re able to spend some time to this project and it gets enough attention, it might get traction and others might fork and create pull requests to enhance further?

1 Like

Which are fully using DSA since 24.10.x and up, right now.

Probably even a subset of that. I’m focusing on the feature set I’d like to use in my network. Since it’s a fairly typical one that should be sufficient for a lot of people. Let’s see if people come up with pull request for features that they want afterwards.

2 Likes

This is pretty neat, do you think this could be docker deployable ?

( at risk of introducing scope runaway → I run docker containers in my “main” OpenWRT router - BPI-R3 or OpenWRT One with external storage , an drunning the SOHO managment form that device kindof makes sense for on premesis managment of the other devices which act as AP for the common LAN, as well as GuestAP - other VLAN/ single office WLANs)

I have not done it with Pocketbase yet, but building multiarch images with Ko / GoReleaser that run on arm64 hosts is straight forward (once you figure out the setup)

1 Like