It has 8 2.5Gbps PASSIVE POE ports (passive POE not available on stock Xyzel FW), and 2 SPF+ cages. Here's the dashboard:

I took some inspiration from familiar switches and manufacturers that we've all worked with.

This switch is powered by a Meanwell LAD360D - a 360W 54V PSU, UPS, and battery charger. A great device. We wire 4 12V SLA batteries in series for battery backup. We install these switches on residential rooftops, and the power goes in a Hana Wireless fiberglass box on the side of the home.

We run a 12 gauge UV rated SJ line up to the roof where the switch lives. The switch is in a Ubiquiti Flex Pro box. We drill two holes in the back of the box for fans.

The fans are powered by POE out on a configurable port, and they are triggered by the switch's own temp reading. You can configure what temperature triggers the fans, and what temp turns them off. We use a tiny mikrotik POE splitter and made the fan port the customer access port for the home owner. Home owner gets 2.5Gbps capacity and the port serves a dual function and also powers the fans. One intake and one outtake fan. 2.5G POE switches running hot isn't an excuse to not make a product because there is always a solution to every problem! You can see the fans doing their job here:

You can also see the heater and Siklu snow melter - the heater kicks on like the fan, forced POE out. I don't anticipate needing it because the POE output will keep the switch warm enough I think - it runs pretty warm as most 2.5G POE switches do. The Siklu snow melter is a pretty slick one and is a feature mainly for our area (we are in Utah ❄️). You put the switch's GPS coords into the setting card, and when there is forecasted snow (the switch is connected to weather.gov) it will turn POE on automatically to keep your backhaul dishes clean from snow.

The switch will tell you the immediate neighbor IP, MAC, name, make and model, and firmware version using LLDP data. I'm shocked no other switch does this (at least none that I know of).

My favorite feature is how it handles power outages. When the power goes out, the switch pulls battery off the PSU, and there is a voltage drop. The switch sees this and will send an email to you letting you know that power is out, and will provide an estimated battery runtime based on the battery capacity data that you enter into the switch. Once a power outage commences, the switch will refresh and check the MAC table of each AP port. If there are no MACs present (like if there is an area wide power outage and all the CPEs on an AP are offline) the switch will drop power on that AP's port to boost battery runtime for APs that still have customers connected. Once AC is restored, it turns the ports that it killed back on. All of this happens automatically with 0 human intervention. It handles power outages like a dream.

Other neat stuff like:

- 200+ watts of POE budget (documentation for the device states 130w but I learned that is only because the PSU that ships in box with the switch is only capable of 130W, and the switch itself is capable of more)

- 60w per port (it has powered a Siklu 8010FX)

- Desktop AND Mobile optimized UI - logging into a UISP switch on your phone browser kinda sucks

- port isolation

- LAGs (with working port isolation - for some reason UI switches don't allow port iso on LAGs)

- flexible VLAN configuration

- Watchdog

- it will email you letting you know it's time to replace the batteries once they are 4 years old

- POE Forced on (passive) or POE Auto (at)

- Keeps the last hours worth of traffic data for troubleshooting

Here is in action:

A quirk - this is a hardware issue that Claude can't solve. There is a pretty serious ground isolation issue where if the radios are using shielded cables, there will be ground loops and all sorts of weird power issues will present themselves. For example, radios will stay powered even when POE is turned off on the port, because power is making it out the ground. To solve this problem, we use plastic ends on the switch side, and ground all the CAT5 drain wires to a bus bar in the box to keep the ground from passing through the switch. The radios and the switch are grounded independently. Slight inconvenience, but problem solved.

This post is not an attempt to sell a firmware image for a 3rd party switch (legally not for sale, but I'm happy to share the .bin with anyone interested in trying it) - it is an attempt to wake UI the freak up. Using AI, this firmware was made in less than 2 months for existing hardware - the S16 is 11 years old! That's insane. Please remove WISPs from the back burner! There is no excuse now that AI has made it possible for a simpleton like me to create something cool like this. I sincerely hope UI will not forget their roots and start showing WISPs some love! It is maddening watching Unifi get a new product every other week- UISP sales would absolutely pick up if WISPs were treated the same, this is a fact. It feels like UI is acting like the golden age of WISPs is over, but that is just not true. We operate in an area with extremely dense competition - municipal fiber, the big evil cable company, big fiber, and of course Starlink - and we're still growing like crazy with Wave and excellent customer service. @UI-Team WISPs aren't nearly as obsolete as you seem to believe!

Thank you for your time 🙏

Either way we updated them to 1.12.2 and we are seeing other issues at this point. 2 days after the reboot one of our switches decided to turn off POE for a few hours and then turned it back on. We have never seen this issue before but now I'm thinking we need to roll everything back again because we cant have equipment just turning off for no reason.

I have self-hosted UISP server based on docker nico640/docker-unms

With UISP i have connected

• 1 edge router x
• 2 edge router x sfp (erx-sfp-1, erx-sfp-2)
• 2 nanostation loco m2 (loco-m2-1, loco-m2-2)

The loco-m2-1 is connected and powered with Poe to erx-sfp-1.

The 2 loco-m2 stations cannot get connection to uisp due to this error

The problem could be the bolded row below

Aug 16 08:59:48 udapi-bridge[1522]: unms: connecting to 57.131.24.77:443

Aug 16 08:59:48 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-status, id: fake

Aug 16 08:59:48 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-startPing, id: fake

Aug 16 08:59:48 udapi-bridge[1522]: unms rx: name=unms-status socket=internal id=fake session=d7caa3a payload={  "timestamp":1786863588506,  "message":"unms: connecting to 57.131.24.77:443",  "logLevel":1 }

Aug 16 08:59:48 udapi-bridge[1522]: unms rx: name=unms-startPing socket=internal id=fake session=d7caa3a payload={  "pingHost":"57.131.24.77",  "pingIntervalWhenUp":30000,  "pingIntervalWhenDown":5000 }

Aug 16 08:59:48 udapi-bridge[1522]: INTERNALAPI recv: sk: internal, name: unms-startPing, id: fake, 0

Aug 16 08:59:49 udapi-bridge[1522]: 57.131.24.77: 0.025ms, avg: 0.085ms (+/-0.025ms^2), min: 0.085ms, max: 0.000ms, loss: 0.00%

Aug 16 08:59:50 udapi-bridge[1522]: 57.131.24.77: 0.025ms, avg: 0.555ms (+/-0.025ms^2), min: 0.320ms, max: 0.000ms, loss: 0.00%

Aug 16 08:59:51 udapi-bridge[1522]: ping 57.131.24.77: 25.320000

Aug 16 08:59:53 udapi-bridge[1522]: LLDP: Touching DB entry (local port 1, name: eth0): from: e4:38:83:dd:53:6b , remote port: 'eth4' (type: 'Locally assigned'), ttl: 240

Aug 16 09:00:09 udapi-bridge[1522]: connection error (unms.faresoftware.it:443): Timed out waiting SSL

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-status, id: fake

Aug 16 09:00:09 udapi-bridge[1522]: session_destroy: session UNMS(0x49df98) not found

Aug 16 09:00:09 udapi-bridge[1522]: unms rx: name=unms-status socket=internal id=fake session=d7caa3a payload={  "timestamp":1786863609001,  "message":"connection error (unms.faresoftware.it:443): Timed out waiting SSL",  "logLevel":3,  "statusTe

Aug 16 09:00:09 udapi-bridge[1522]: unms: connecting to 57.131.24.77:443

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-status, id: fake

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-startPing, id: fake

Aug 16 09:00:09 udapi-bridge[1522]: unms rx: name=unms-status socket=internal id=fake session=d7caa3a payload={  "timestamp":1786863609506,  "message":"unms: connecting to 57.131.24.77:443",  "logLevel":1 }

Aug 16 09:00:09 udapi-bridge[1522]: unms rx: name=unms-startPing socket=internal id=fake session=d7caa3a payload={  "pingHost":"57.131.24.77",  "pingIntervalWhenUp":30000,  "pingIntervalWhenDown":5000 }

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI recv: sk: internal, name: unms-startPing, id: fake, 0

Aug 16 09:00:10 udapi-bridge[1522]: 57.131.24.77: 0.034ms, avg: 0.514ms (+/-0.034ms^2), min: 0.514ms, max: 0.000ms, loss: 0.00%

Aug 16 09:00:11 udapi-bridge[1522]: 57.131.24.77: 0.025ms, avg: 0.485ms (+/-0.030ms^2), min: 0.000ms, max: 0.040ms, loss: 0.00%

Aug 16 09:00:12 udapi-bridge[1522]: ping 57.131.24.77: 30.000000

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Sending LLDP packet on port 1 (eth0)

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Some data on port 2 (eth1) were not sent

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Sending LLDP packet on port 2 (eth1)

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Sending LLDP packet on port 3 (wifi0)

How can solve this?

Best regards,

MZ

I'm experiencing a strange issue with several UISP-S switches. (all have the newest available Version, UISP has 3.0.159)

As long as the switches are connected to and managed by the UISP controller, they generate RSTP topology changes exactly every 8 hours. This results in MAC table flushes and unnecessary network reconvergence, even though there are no physical link changes, no device reboots, and no configuration changes.

What I observed

• Multiple UISP-S switches are managed by UISP.
• Every 8 hours, the switches report RSTP topology changes.
• The timing is very consistent and repeats continuously.
• The network itself is physically stable.

Troubleshooting

To isolate the problem, I performed the following test:

1. Put all UISP-S switches into Maintenance Mode. (UISP-S-Plus are working)
2. Removed the UISP URL from each switch so they were no longer connected to the UISP controller.

After doing this:

• The RSTP topology changes completely stopped.
• The network has remained stable for an extended period.
• No more periodic topology change events occur.

When the switches are reconnected to UISP, the problem returns.

Network

• UISP-S and UISP-S Pro switches
• RSTP enabled
• Managed through UISP
• Stable Layer 2 topology
• No loops or unstable links detected

Question

Has anyone else experienced periodic RSTP topology changes every 8 hours while UISP is managing UISP-S switches?

It appears that something in the communication between UISP and the switches may be triggering RSTP events, although I have not yet identified the exact mechanism.

Any ideas or confirmation from other users would be greatly appreciated.

Thank you!

We have a semi-public wi-fi network (which I don't administer) with several access points (each a different SSID), fed by a starlink system. At one location the wi-fi signal isn't quite strong enough for handheld devices to access, so I'm using the Rocket with an Omni antenna as a wireless client (station) with an Ethernet connection to the WAN port of another [consumer grade] Zoom router for devices in the immediate area.

The public network assigns IPs in the 192.168.1.x range. I've set up the Rocket for station wds wireless mode, and bridge for network mode. It generally shows a good wireless signal from the public AP in the -70 to -77 dbm range.

The local Zoom gets a DHCP IP address passed through the Rocket (currently 192.168.1.232) on its WAN port, and gateway and DNS are both 192.168.1.1. On the wireless side, the local route assigns IPs in the 192.168.2.x range.

The issue is that while it works well for the most part, I frequently lose Internet connectivity. I can still connect through to the Rocket at 192.168.1.20 and see that it's associated with the public AP with a good signal, but "no Internet" and pinging an outside IP like 1.1.1.1 fails. Then after a minute or two it just works again.

If I connect a device directly to the public AP (obviously I have to get closer to the AP to get a strong enough signal) I don't experience these interruptions.

I seem to recall a similar problem some years ago when I was administering the network (a completely different system) and it was resolved IIRC with an gateway and/or DNS change, but I don't really remember the details. Do I need to set those manually in the local router or is the default 192.168.1.1 correct?

Or would I be better setting the Rocket as a router instead of bridge and using the Zoom router as a simple AP?

I also tried disabling DHCP and NAT on the Zoom router making it into a simple AP (?) but then the local devices never get an IP.

https://uisp.community.ui.com/releases/86253408-92da-4cd7-9391-784d85a1ffcc?replyId=c8a4a507-7dfb-45f8-bbfa-90691a716315

But.. what an unpleasant surprise..

You can only setup basic things. You are forced to use app.

You can't set any network settings if port is unplugged. So you can't prepare the router before hand.

The app thinks it is smarter than you all the time.

What a disaster.

And now. After all the hassle I can't even set up dhcp-relay.

What is going on?!

If God gave this router to Adam & Eve and asked them to use Ubiquiti devices to build up Internet in the Great Garden they would not be able to, because uisp-r would be forever complaining that Internet wasn't plugged into Port 1.

To be polite I should maybe say at least one positive thing about the device. Maybe this - power supply looks solid (but the jack connector feels rather cheap).

Are we going to get ARP inspection and IP Source Guard on the Switch Plus, and why does the Switch Pro have a maximum of 256 entries for the binding table? We need the Switch Plus/Pro to catch up to EdgeSwtich in terms of switching features.

Or even better, abandon the failed GUI only / Unifi clone attempt, and introduce more 10G/2.5G solutions to the EdgeMAX products that are still currently being produced.

Did you guys hire Gavin Belson from Hooli?

In the ISP space we are not looking for point-and-click simplicity. We need command line power!

I have suffered a bit with the ipsec site-to-site and remote access configs on my two edgerouter 12.

Hence wanted to share the bugs I found with ChatGPT's help, hopefully will help someone else and with some luck they get fixed in a future release.

Cheers!

ChatGPT's write up:

# EdgeOS / VyOS IPsec & Agile VPN Bug Report

## Bug 1: Duplicate X.509 Private Key Entries Generated in `ipsec.secrets`

### Component

`/opt/vyatta/sbin/vpn-config.pl`

Function:

``` perl

sub get_x509_secret

```

### Description

When multiple site-to-site IPsec peers use the same X.509 private key,

the generated `/etc/ipsec.secrets` contains one identical `: RSA` entry

per peer instead of a single entry per key file.

Example generated output:

``` text

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

```

### Steps to Reproduce

1. Configure multiple site-to-site peers using the same X.509

  certificate and private key.

2. Commit configuration.

3. Inspect:

``` bash

cat /etc/ipsec.secrets

```

### Expected Result

Each private key should appear only once:

``` text

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

```

### Actual Result

One identical entry is generated per peer.

### Consequences

- Unnecessary duplication in generated configuration.

- Causes StrongSwan to repeatedly load the same private key during

  startup and reload operations.

- Increases startup and configuration processing time.

- Becomes increasingly inefficient as the number of tunnels grows.

### Root Cause

`get_x509_secret()` always emits a new secret entry and does not consult

the existing `%key_file_list` deduplication mechanism already used

elsewhere in `vpn-config.pl`.

### Proposed Fix

Before generating the secret entry:

``` perl

return '' if defined($key_file_list{$key_file});

$key_file_list{$key_file} = 1;

```

Only emit the `: RSA` line when the key file has not already been

processed.

------------------------------------------------------------------------

## Bug 2: Agile VPN Generates Incorrect `rightca` Value

### Component

`/opt/vyatta/share/perl5/Vyatta/AgileConfig.pm`

### Description

The generated Agile VPN configuration uses the local configured CA when

generating the StrongSwan `rightca=` directive instead of the configured

remote CA.

### Steps to Reproduce

1. Configure Agile VPN with distinct local and remote CA certificates.

2. Generate Agile VPN configuration.

3. Inspect the generated connection definition.

### Expected Result

``` text

rightca=<configured remote CA>

```

### Actual Result

``` text

rightca=<local CA>

```

### Consequences

- Certificate validation may be performed against the wrong CA.

- Interoperability problems when local and remote trust anchors

  differ.

- Can lead to failed authentication or incorrect trust validation.

### Root Cause

The Agile configuration generator uses:

``` perl

$self->{_x509_rcacert}

```

when constructing `rightca=` instead of the remote CA variable.

### Proposed Fix

Use the configured remote CA when generating:

``` perl

$right_ca = "rightca=" . $remote_ca;

```

instead of referencing the local CA object.

------------------------------------------------------------------------

## Bug 3: Agile VPN Regeneration Is Not Triggered By Site-to-Site IPsec Commits

### Components

- `/opt/vyatta/share/vyatta-cfg/templates/vpn/ipsec/remote-access/node.def`

- `/opt/vyatta/share/vyatta-cfg/templates/vpn/ipsec/node.def`

### Description

Agile VPN configuration regeneration is only attached to the

`vpn ipsec remote-access` configuration tree.

Changes under:

``` text

vpn ipsec site-to-site

```

invoke `vpn-config.pl` and regenerate IPsec configuration, but do not

invoke `vyos-update-agile.pl`.

As a result, Agile VPN configuration can become stale or be partially

overwritten after unrelated IPsec changes.

### Steps to Reproduce

1. Configure Agile VPN.

2. Configure one or more site-to-site tunnels.

3. Commit.

4. Modify only a site-to-site tunnel parameter.

5. Commit again.

6. Observe that `vyos-update-agile.pl` is not executed.

### Expected Result

Any IPsec commit affecting generated IPsec configuration should trigger

Agile VPN regeneration.

### Actual Result

Agile VPN regeneration occurs only when something under:

``` text

vpn ipsec remote-access

```

changes.

### Consequences

- Agile VPN generated configuration can become inconsistent with

  current IPsec configuration.

- Site-to-site commits and remote-access commits follow different

  regeneration paths.

- Configuration correctness depends on commit order and on whether

  remote-access settings have changed recently.

### Root Cause

The regeneration hook exists only in:

``` text

vpn/ipsec/remote-access/node.def

```

and not at the broader:

``` text

vpn/ipsec

```

level.

### Proposed Fix

Attach Agile regeneration to the IPsec configuration tree itself so that

all IPsec-related commits invoke:

``` bash

sudo /opt/vyatta/sbin/vyos-update-agile.pl

```

Additionally, ensure template priorities are ordered correctly to avoid

priority inversion warnings when both IPsec-level and

remote-access-level hooks are present.

------------------------------------------------------------------------

## Summary

Three independent issues were identified:

1. Duplicate X.509 key entries generated in `ipsec.secrets`.

2. Incorrect CA reference used when generating Agile VPN `rightca`.

3. Agile VPN regeneration not triggered by site-to-site IPsec commits.

All three issues are reproducible on EdgeOS 3.0.1 / StrongSwan 5.6.3 and

affect generated IPsec configuration rather than user configuration.

We use snmp oid .1.3.6.1.2.1.17.1.1.0 for determening switch mac address but this snmp oid does not return uisp poe switch mac address

We found that usip poe switch mac address can be found using oid

.1.3.6.1.2.1.55.1.5.1.8.3

@UI-Team may be it can be fixed?

*intente varias formas para configurar el correo SMTP para envió de correos y no salgo del error “SMTP server connection is not working properly. SMTP configuration was reverted back”

*Otro punto es que logre meter mi backup del uisp cloud al uisp local server, me costo mucho trabajo pero pude hacerlo funcionar con un dominio en cloudflare, puedo verlo desde mi app y desde fuera de mi red. El problema que tambien presento es: todas las AP Rocket 5ac lite, y las estaciones litebeam 5ac si me las reconoció el servidor y me aparecen en lineá, pero todas las estaciones con litebeam m5 de primera generación me aparecen fuera de lineá, ya intente meter la nueva key, pero no logro hacer que se visualice en UISP Local server. Ojala que puedan ayudarme.

I ended up switching out my docker UISP server for the UISP-Console so I dropped the Unifi device on that side of VPN and am going through the new console.

Tried setting up firewall on my own and then I followed this:

https://community.ui.com/questions/UISP-Console-firewall-rules-for-VPN/ab8bf1db-84e0-4c21-b4e0-5f63c3b01286

I was on righttrack but did not use the Group negation. Now it half way works.

Now the only problem is:

Tower Network. 192.168.200.0/24

UISP Network 192.168.210.0/24

When I am on the tower network and try and connect to devices on 210.0 I can.

When I am on the UISP network and try to connect to devices on the 200.0 network, I can't.

here are the two firewall and one Nat rule.

Tower Connection is UNIFI router setup for zone firewall. This was working fine when setup was UNIFI router to UNIFI router. But moved to the console device. So I had to do nothing on the tower side.

I need to be able to figure out which user, his private IP, port, translation to what public address has been made and what was the destination IP and port.

default log sends what is going on with the router

conntrack is not sending all data (only external IP/port and destination IP/port)

netflow is doing the same but different way

there is no data to correspond from DHCP servers at all or I can't track it down.

Is there any way to get it out of the routers? :)

Ps. This is required by law in Poland right now, so it is a must have or change of the hardware...

I setup an IPSec Point to point VPN.

No clear direction on setting up the Firewall rules.

There is one post on this but references back to the edge router.

I am trying to figure out using the Router side of the Console the GUI firewall settings.

for UDP port 500 and 4500 and

ESP

and Masquerade setting under NAT part

what do I fill in here for the Firewall rules?

What I see is after a reboot, it appears to come up and "uosserver status" reports that its healthy, but the service is not available on port 11443, and the logs tell a story of it being unhappy. The specific error in the logs is "Supervisor error connecting: WebSocket handshake failed":

 $ uosserver status
CONTAINER ID  NAMES       CREATED                                  RUNNING FOR   STATUS
367ff67232e0  uosserver   2026-05-19 22:53:59.577314064 -0700 PDT  15 hours ago  Up 23 minutes (healthy)

Host service:

● uosserver.service - Unifi OS Service
     Loaded: loaded (/etc/systemd/system/uosserver.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-05-20 13:20:02 PDT; 23min ago
 Invocation: d05bdc4112594a5283f54ffcd4b3417f
   Main PID: 985 (uosserver-servi)
      Tasks: 12 (limit: 4635)
     Memory: 58.6M (peak: 80.6M)
        CPU: 28.493s
     CGroup: /system.slice/uosserver.service
             ├─985 /var/lib/uosserver/bin/uosserver-service
             └─992 /var/lib/uosserver/bin/discovery

May 20 13:39:06 gnome1 uosserver-service[985]:     1: Connection refused (os error 111)
May 20 13:41:36 gnome1 uosserver-service[985]:  INFO Supervisor connecting
May 20 13:41:36 gnome1 uosserver-service[985]:  INFO Waiting for container 'uosserver' to start (timeout: 60s)
May 20 13:41:37 gnome1 uosserver-service[985]:  INFO Container 'uosserver' is running. (elapsed: 0.0s)
May 20 13:41:37 gnome1 uosserver-service[985]:  INFO Waiting for systemd to be ready (timeout: 60s)
May 20 13:41:37 gnome1 uosserver-service[985]:  INFO Systemd is ready. (elapsed: 0.0s)
May 20 13:41:39 gnome1 uosserver-service[985]:  INFO Supervisor error connecting: WebSocket handshake failed
May 20 13:41:39 gnome1 uosserver-service[985]: Caused by:
May 20 13:41:39 gnome1 uosserver-service[985]:     0: IO error: Connection refused (os error 111)
May 20 13:41:39 gnome1 uosserver-service[985]:     1: Connection refused (os error 111)

When this happens, the core service shows a contemporaneous error:

● unifi-core.service - UniFi Core
     Loaded: loaded (/lib/systemd/system/unifi-core.service; enabled; vendor preset: enabled)
    Drop-In: /lib/systemd/system/unifi-core.service.d
             └─cap.conf, memory.conf
     Active: active (running) since Wed 2026-05-20 13:20:52 PDT; 22min ago
    Process: 461 ExecStartPre=/usr/share/unifi-core/app/hooks/pre-start (code=exited, status=0/SUCCESS)
   Main PID: 505 (unifi-core)
      Tasks: 270 (limit: 4635)
     Memory: 288.2M (max: 1.0G swap max: 200.0M)
        CPU: 1min 57.948s
     CGroup: /system.slice/unifi-core.service
             └─505 unifi-core

May 20 13:40:52 367ff67232e0 sudo[3084]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
May 20 13:40:53 367ff67232e0 sudo[3084]: pam_unix(sudo:session): session closed for user root
May 20 13:40:53 367ff67232e0 sudo[3086]:     root : PWD=/usr/share/unifi-core/app ; USER=root ; COMMAND=/bin/systemctl status system.slice --no-pager --lines=0
May 20 13:40:53 367ff67232e0 sudo[3086]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
May 20 13:40:53 367ff67232e0 sudo[3086]: pam_unix(sudo:session): session closed for user root
May 20 13:40:53 367ff67232e0 sudo[3088]:     root : PWD=/usr/share/unifi-core/app ; USER=root ; COMMAND=/bin/systemctl show --property=MemoryCurrent --property=Id server main journald logind go core directory identity-update
May 20 13:40:53 367ff67232e0 sudo[3088]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
May 20 13:40:53 367ff67232e0 sudo[3088]: pam_unix(sudo:session): session closed for user root
May 20 13:41:10 367ff67232e0 node24[505]:   Error: read ECONNRESET
May 20 13:41:10 367ff67232e0 node24[505]:       at TCP.onStreamRead (node:internal/stream_base_commons:216:20)

I have this installed on Debian 13.5 with all packages up to date. The host is a freshly installed host with nothing else running on it. And I am running it on x86_64 hardware - no VM layers. The only deviation from the documented procedures was that I added "After=dbus.service systemd-logind.service user@####.service" to the systemd unit file to address a race condition, a solution I have used on other UOS servers.

Often, restarting the service brings it up in a healthy state. But that's not really acceptable. I want my management console to come back up reliably from a powered off state.

I have another machine that is also debian 13.5 that also was installed this way that does not have this problem.

The most obvious thing I can think of is the machine that doesn't work is lower powered. It works on a host that is a 128 core beast that does a bunch of other things. I want to run this on an old AMD Geode machine I have so it can quietly do its thing undisturbed on very few watts in the corner of my lab. It's low power, but should be adequate. 4GB RAM, 128 GB disk, 4 (slow) cores, 4GB Swap, 2GB /tmp. Specifically, it's a PCEngines APU2 board. (and like I said, it does come up on manual restart, but not reliably on system boot).

Any advice on what might need tuning to make this more reliable?

Thanks.

--- Carl

Adding the second line would allow the router downstream to also via DHCP or SLACC to delegate /64 by using a /62 from

2602:271:88:a008:: - 2602:271:88:afff:: this is a fundamental feature of being a ISP and using IPv6

# cat /run/dnsmasq.conf.d/dhcp.dhcpServers-Unnamed_3870007651.conf

no-dhcp-interface=lo

interface=switch0.1

enable-ra

ra-param=switch0.1

dhcp-range=set:Unnamed_3870007651,2602:271:88:a000::2,2602:271:88:a000:ffff:ffff:ffff:fffe,slaac,64,86400

dhcp-range=2602:271:88:a008::,2602:271:88:afff::,52,62,86400

dhcp-option=tag:Unnamed_3870007651,option6:dns-server,[::]