I would like to report a potential bug in UISP 3.1.70 affecting third-party MikroTik devices monitored via SNMP.

The devices are successfully discovered, their interfaces are retrieved, and authorization completes successfully. However, shortly afterward, they disappear from the UISP interface.

After investigating the PostgreSQL database, I confirmed that the device records are actually deleted, rather than merely disconnected or hidden.

Environment

• UISP: 3.1.70, self-hosted Docker deployment

• PostgreSQL: 17.3

• MikroTik RouterOS: 7.25

• Monitoring: SNMP v2c

• UISP device type: blackBox

Investigation and findings

Using a temporary PostgreSQL audit trigger, I traced the device deletion to the execution of:

SELECT device_id, site_id, prev_authorized, prev_site_id
FROM unms_auto_authorize_devices();

Inspection of this function revealed a deduplication mechanism that compares MAC addresses from different devices and their interfaces.

One of the matching conditions is:

JOIN blackbox b ON (b.interface_mac = di.mac)

The function then removes records considered redundant:

DELETE FROM device d
USING redundant_blackbox rb
WHERE d.device_id = rb.redundant_device_id

Further analysis identified a possible cause.

RouterOS 7.25 exposes its built-in system loopback interface (lo) through SNMP with the following values:

Interface: lo
Type: loopback
MAC: 00:00:00:00:00:00
SNMP OID: 1.3.6.1.2.1.2.2.1.6.24

A second temporary database audit confirmed interface-to-interface MAC matches involving 00:00:00:00:00:00 and other existing devices.

This strongly suggests that UISP treats the all-zero MAC address as a valid identifier when detecting duplicate devices, potentially causing legitimate MikroTik devices to be incorrectly classified as redundant blackBox records and deleted.

Troubleshooting performed

• Verified successful SNMP communication and interface discovery.

• Confirmed that authorization returns HTTP 200.

• Tested different Site assignments.

• Verified that no primary MAC or management IP conflict was responsible.

• Confirmed that the RouterOS built-in lo interface does not expose a configurable MAC address.

• Tested RouterOS denied-oids as a workaround, but it made the entire ifPhysAddress column unavailable. The change was reverted.

I do not want to modify UISP's internal PostgreSQL functions or change the system loopback interface on MikroTik devices.

Questions

1. Is this a known issue with third-party SNMP devices in UISP?

2. Could the engineering team review how unms_auto_authorize_devices() handles all-zero interface MAC addresses?

3. Has this behavior been corrected in a newer UISP version?

4. Is there a supported workaround to prevent this false duplicate detection?

In my opinion, 00:00:00:00:00:00 should not be treated as a unique MAC address for device deduplication.

Thank you for your help.

Please add support for selecting SNMPv3 authentication and privacy protocols when monitoring third-party devices in UISP. This should include support for modern standards such as SHA-256 authentication and AES-128 encryption.

Use Case:

Many third party devices/appliances can be configured for SNMPv3 using SHA-256/AES-128, but UISP does not appear to provide options to specify these protocols other than v1/2c, preventing successful monitoring and discovery.

Benefit:

This enhancement would improve support for multi-vendor networks and reduce the need for separate monitoring platforms for standards-compliant SNMPv3 devices.

PHP released 8.3.36 today (Oct 21, 2026) to fix two critical unauthenticated RCE vulnerabilities:

- CVE-2026-109618 - RCE via OOM corruption

- CVE-2026-109619 - RCE via stale global state

The PHP security team states that updating is the only complete mitigation.

We run UCRM and verified the bundled PHP versions by inspecting the published images:

- UCRM 4.6.13: PHP 8.3.32

- UCRM 4.6.15 (latest on Docker Hub): PHP 8.3.35

- Fixed version: PHP 8.3.36

So even the latest UCRM image is still vulnerable. Could you confirm:

1. When will a UCRM image built with PHP 8.3.36 (or a backported fix) be published?

2. Will it be a new tag such as 4.6.16, or a rebuild of 4.6.15?

3. Is there any UCRM-specific interim guidance beyond the PHP-level mitigations (memory_limit=-1, lower post_max_size, session.upload_progress.enabled=0)?

We have taken our UCRM container offline as a precaution, which is currently affecting billing and payment webhooks, so an ETA would be very helpful. We’re happy to test a pre-release image if that speeds things up.

Thanks!

What esle could have been not migrated?

The process I ran was to load the uisp backup in the new server.

Thanks in advance

W

I logged into the UISP Portal and I am being greeted with a "Welcome Back" message and a button that says "Create new UISP Cloud Hosting." However, I already had an active hosting instance, which I urgently need right now to record payments and check my network status.

Additionally, my mobile app is displaying the error "Application is unreachable."

My account payments are completely up to date. I need to know what happened and how this issue will be resolved as soon as possible. This is an urgent matter for my business.

I don't have answer in the Live Chat.

Last refresh of SSL certificate had failed.

Timestamp: Today at 9:02

Error: <html>\r 

<head><title>500 Internal Server Error</title></head>\r 

<body>\r 

<center><h1>500 Internal Server Error</h1></center>\r 

<hr><center>openresty</center>\r 

</body>\r 

</html>\r

Thoughts?

I would like to propose an improvement for the UISP Map view to help network administrators manage infrastructure lifecycles more efficiently.

Current Situation:

In my network management workflow, I do not use the CRM module, but I frequently decommission older sites. I need to keep these empty sites on the map to maintain a historical record of our locations. However, this fills the map with "gray dots" (empty sites), making the interface cluttered and difficult to read when trying to focus on live operations.

Proposed Solution:

It would be extremely helpful to replace the basic map views with an advanced filter checkbox menu, allowing users to toggle the visibility of sites based on their actual state:

• [ ] Show Online Sites (Active nodes)
• [ ] Show Offline Sites (Nodes requiring attention/maintenance)
• [ ] Show Empty/Decommissioned Sites (Placeholder locations with no devices assigned)

Benefits:

• Flexible Visibility: Administrators can instantly hide all decommissioned "gray dots" when monitoring live network health, but easily turn them back on when planning new deployments.
• Better Troubleshooting: Allows focusing exclusively on offline nodes without visual clutter.
• Improved Workflow: Supports proper lifecycle tracking of network locations directly on the map.

This feature would drastically improve the daily operations of many network administrators who need to keep historical data without sacrificing map clarity. If you agree, please upvote!

Thank you. @UI-Team

I have an open ticket since Sept 25th regarding our UISP instance performance and reachability. We have had issues all weekend and after several reboots its still running off. I am posting here to see if there is anyone who can respond to my ticket please. #6007081 I believe is the ticket number

There is currently an issue in the CRM where if an account is placed on suspension due to non-payment, the invoice for that entire billing cycle is pushed onto the account instead of the prorated bill up to the time of suspension. This then requires that the account be manually credited from the date of suspension to the end of the billing cycle or the date of reconnection. This is causing unnecessary work due to additional steps becoming required to maintain the accuracy of the balance on the client accounts in the CRM.

There is a critical routing/validation limitation within the UISP CRM API endpoint PATCH /api/v1.0/clients/{id} when attempting to update custom attributes.

If a client record has an existing record/value stored for a specific customAttributeId (even a blank string initialized via the Web UI), the PATCH payload executes perfectly. However, if the custom attribute has never been touched or initialized for that specific client, the backend entity manager fails to find a database row index for that sub-resource, causing the entire API call to reject with a misleading 404 Not Found or a structural mutation failure.

Because POST /api/v1.0/clients/{id}/attributes throws a 405 Method Not Allowed, there is currently no programmatic way via the API to initialize a brand-new custom attribute for an existing client unless the data is manually input or saved via the frontend Web UI framework first.

This completely blocks large-scale data migrations from external data systems into UISP via scripting.

Reproduce

1. Create a Custom Attribute in CRM Settings (e.g., ID: 21).
2. Create or find an existing client that has never had data typed into this custom attribute via the UI (the "attributes": [] array returns empty on a GET request).
3. Attempt to add data to this attribute by sending a PATCH request to /api/v1.0/clients/{id} with the payload:

{ "attributes": [ { "customAttributeId": 21, "value": "TestValue" } ] }

Expected Result: The API should dynamically initialize/insert the missing attribute relation into the client database profile.

Actual Result: The server returns a {"code":404,"message":"Not Found"} response.

is there a way around this? May we request if this can be updated, the validation/ORM logic for the /clients/{id} endpoint. If a PATCH or PUT request contains a valid customAttributeId that exists globally in the system but does not yet exist for that specific client entity, the backend should perform an upsert (Insert if missing, Update if exists) rather than dropping the request with an unhandled 404 entity error.

Access points and stations on firmware 8.7.25

The API endpoint /devices/airmaxes/{id}/config/wireless is returning the incorrect "mode" string for Airmax devices.

On a PrismStation 5AC, that API endpoint returns the "mode" as "ap-ptp", even though it is actually set to PTMP.

On a Litebeam 5AC, that API endpoint returns the mode as "sta-ptp" instead of "sta-ptmp". If you use that endpoint to update the config with "sta-ptp" as the mode, the Litebeam accepts that config and disconnects from its AP because it is now in the wrong mode.

@UI-Team

Attachments:

• Screenshot 2026-09-21 233848.png
• Screenshot 2026-09-21 234632.png
• Screenshot 2026-09-21 234912.png

It's a plugin in CRM that connects to UISP via API. It as admin access to UISP so you can change AP channels from the plugin.

Click the plugin icon and open the map, and it will open this tool. It uses free ESRI world imagery satellite data, but you can connect Google Maps data with a free Google Maps API key in the plugin settings.

You can see on the left panel you can swap between your 60GHz and 5GHz networks. It has every AP in your network placed by its internal GPS coords, and the heading is estimated based on customer location on the AP. Each AP is color coded to a specific channel. Solid color means full channel; diagonal lines mean half channel. The tool takes terrain data into consideration (it pulls terrain data from Amazon - they have free terrain data available to the public for some reason. That being said, this may only work in the US), so you can count on the tool's coverage estimate to be pretty accurate. APs that are highlighted with a dotted yellow line show a channel conflict with another AP in your network.

You can toggle the map between full color map and b&w so it is easier to distinguish channels. You can toggle backhauls on/off. You can enable customer location icons and customer links to better visualize what your network looks like. I have them disabled to protect our customers' privacy but works great to better see where there could be self-interference, or if there is a better AP that the customer could be connected to.

If you click on a sector, will bring up the following information.

Here you can see the tool doing math to find the best possible channel for the AP to operate on. You can select the recommended channel and hit apply, and it will change that APs channel to the recommended channel instantly. The map updates once every 30 seconds, so you'll see the change apply to your map shortly. This is what a clean, conflictless AP looks like.

The tool takes lots of variables into consideration to establish an opinion on the conflict severity. It has a 3-tiered conflict rating: Low conflict, medium conflict, and high conflict. It creates a conflict rating based on AP heading, overlap, channels used (and channel width), whether GPS sync is enabled, AP heading, azimuth and vertical beam, surrounding terrain, customer locations, among a few other variables. Here you can see it taking the 3 degree vert beam of the Wave AP into consideration.

It will also show you relevant information about your network in the bottom left hand panel that UISP may miss.

It works by populating all of your sites into the tool, you can scroll and select each individual site, and you show and hide individual APs so you don't get overwhelmed with the amount of data on your map.

It has changed how we channel plan, and it is AMAZING to be able to visualize the Wave network with a color-coded system.

I am working on getting Wave 5GHz backup radios into the tool, but haven't cracked that egg yet.

For your AirMAX devices, it pulls the data that you have input into the radio - since most of UI's 5GHz APs have SMA connectors. You can update the antenna type width, gain, ect. You can see here that 5GHz operates similarly:

The information card shows information like:

• GPS sync
• Client count
• Beamwidth of AP
• Distance to furthest client
• square km's of coverage area, ect

You can also edit information about the APs, and the information that you manually put in will trump the data that the tool pulled from UISP in case UISP has something wrong.

This is not a replacement for UISP by any means, it isn't magic, and it may get some things wrong - but you can use it as a trustworthy tool to help you channel plan more effectively. PM me if you want the tool and I'll email the zip file to you. If you don't like something about it, you can upload the zip file to Claude and it can make any changes that you'd like.

It's important that we all channel plan as accurately as we possibly can not only so we don't shoot ourselves in the foot, but also so we can be good neighbors. Thanks!

UISP 3.0.159

Console 5.5.0

It seems that the UISP Console that the "Maps" are being blocked by the provider. Just happened to notice it today.

Environment

UISP Application 3.0.159 (self-hosted), ~240 EdgeRouters (ER-4 / ER-12 / ER-Lite / ER-10X) with the web UI moved off 443:

set service gui https-port 9443

Problem

UISP always links to the device as https://<ip>/ – in the devices list (IP Address column), in the device panel (Overview → IP Address), on the dashboard, and in the ⋮ → "Open Device Web UI" action. For every EdgeRouter that uses a non-default GUI port the link lands on whatever is on 443 (nothing, or a different service). There is no place in UISP to tell it the port.

The information is already there: UISP keeps the router's config backup, where the port is a single line (service gui https-port N), and airMAX/airFiber/Wave already get an httpsPort back from POST /v2.1/devices/{id}/iplink/redirect – EdgeRouters are just not covered.

Request

Any of these, in order of preference:

1. Read service gui https-port from the EdgeRouter configuration and build the link with it (zero configuration for the user).
2. A per-device "Web UI port" field in the device settings, with a global default under Settings → Devices.
3. At least a global default for EdgeRouters.

Same applies to service gui http-port if the link protocol is ever made configurable.

What we do in the meantime (for anyone in the same situation)

Two edits in the frontend bundle (public/assets/index-*.js inside the unms container), re-applied after every update:

• the IP link component (href: \${protocol}://${ip}/`) → append :9443when the device type iserouter`
• the "Open Device Web UI" action (window.open(\https://${ip}`)`) → same condition, same port

Other device types are untouched (EdgeSwitch stays on 443, airMAX/Wave keep the SSO redirect).

It works, but it is a hack on a minified bundle – hence the request.

A feature that could be added in some future version of UISP, in CRM part. The idea came from a way Starlink is charging or billing a special plan: enterprise plans, called "Priority" plans: "Local Priority" or Global Priority".

Starlink charges in a "Priority" plan by consumption, by GB. I don't know if globally it is the same, but at least it is here in Mexico: amounts of 50GB (one could choose some fixed 500 GB amounts monthly, cheaper by half per GB, and later add more amounts in 50GB steps).

It is a charge based in consumption.

In Residential plans Starlink still charges by a fixed price, with ToS and Fair Policy obviously, trying to mitigate the use of a Residential plan traffic outside of the house that contracted it. It is a mess of course: here in Mexico Starlink is almost only used by WISPs, putting Starlink residential antennas in their towers and exploiting at its max a residential data plan. Just in these months Starlink started to stop that, and is starting to restrict the Residential line when it reaches 5TB.

But the idea is that kind of charge: by consumption. I have been thinking a lot about that and all the useful implications it delivers if also used in residential service.

Residential internet could be charged the same as electricity is charged; by consumption, and stopped being like it is today: a fixed, calculated price. Which generates some problems when trying to offer high speed to the house for a better experience: high speed like 100Mbps, or more, now that ISP industry tends to deliver gigabit plans: Google for example delivers now up to 8 Gbps in its Edge plan. We offer high speed, but then need to mitigate by different ways the misuse of a residential plan as reselling or distributing by other ISP, which could be a mini ISP or a mini WISP who is entering this business.

If we charge by consumption in residential plans, then we could totally kind of forget about if a person or group of people or business could and would use a line to do its own mini business of delivering internet to neighbors or neighborhood; or becoming the wisp of his/her zone. We could offer of course a special plan for that, delivering tools for that guy or group who will be an isp, even mini (neighborhood): public IP, dedicated customer service, etc., what a dedicated (1:1) isp delivers. But our infrastructures would not be abused or overused by this mini ISP that sometimes is hard to discover and mitigate, mini (or big) exploiters of Residential lines (whose prices are calculated for use of devices inside a house).

Charging by GB, with still competitive GB prices, could mean this:

• You house are sharing your WiFi with your neighbours, no problem, you pay for the use they do, for all that traffic that goes and comes from your modem, from your line; it's not to you asking them for cooperation $ or not, or you have the money for all that use. It's like installing, in a 1-installation time, 3 houses or 4 houses, if a house is sharing with 2 or 3.
• You WISP guy are using this residential line of 500Mbps to deliver to another 10 or 20 houses and you know it's difficult for me to notice it or find it is you: no problem, you pay for all that traffic of all those houses. It's like installing in a 1-installation time, 11 or 21 houses at once.
• Etc.

We could have at last control over all that that becomes sometimes a headache to avoid: TTL, conntrack, constant monitoring of consumption, try to know how many and which are the devices (models, names, stuff) used in the house (just to know if over there could there be a router which could mask hundreds of devices as one), reducing speed if we offer "unlimited data" and try to control misuse by reducing speed if funding a "wisp" house, etc.

We could rest about all that: you want to do it (resell, share with neighbours), then do it. I could still offer you a dedicated line for that (reselling), better than a residential line with kind of "generic" customer service, attention mixed with hundred or thousands, instead of dedicated or more focused. But we can rest, because our infrastructure is gaining the proper revenue from all that traffic distributed in all those "hidden" houses.

Imagine electricity charged by fixed monthly or bimonthly amount... that doesn't happen (at least not here in Mexico) because control of all that energy could be totally a mess: a hosue would stop being carefully with lights and use, with consumption, or would install as hell more load into the house without need and caution. Electricity is charged by consumption, right. Or an electrical company could just calculate the max use of a house and charge a fix monthly amount: Your meter is 100amps or 200amps, then I charge for those 200amps you could use or potentially use: it's up to you to put thick electrical wire and all electricity stuff well installed to consume if you want up to 200amps. But not, not useful an viable it seems. So it is charged by consumption: you used very few energy this month, then you pay very few; you used a lot, then now you have a great pay to do.

Internet consumption, internet traffic into the house could be charged the same way.

Well then, UISP could have an optional feature or function to create plans whose billing is by consumption: Maybe by amounts of 50GB, 100GB, 200GB...; or first amount 400GB and consequent amounts in 50GB steps, or do it in a way we could choose any first X amount and stepped X amounts: we could set a first 400GB, 300GB, 350GB, 1TB... and subsequent steps of 50GB, 100GB, 20GB, 1GB, 500GB...

Do I explain myself.

Charging by amount would help a lot,

For a special first great advantage, to deliver high or highest speed possible with more peace of mind, without the need of some special ToS or Fair Policies that try to mitigate misuse of residential lines.

• UISP Application 3.0.159 (self-hosted, Docker), upgraded from 3.0.151
• EdgeRouter devices (EdgeOS), Device → DHCP → DHCP Leases table
• Reproduced in Firefox and Chromium-based browsers, clean profile, no extensions

Steps to reproduce

1. Open an EdgeRouter in UISP → DHCP tab → DHCP Leases.
2. On a row of type Dynamic, click the ⋮ menu → Make static.

Expected

The "DHCP Lease" dialog opens with DHCP Server, IP address and MAC address prefilled from the selected lease (this is what the action is written to do, and how it used to work).

Actual

The dialog opens empty: DHCP Server shows the first server in the list, IP address and MAC address are blank, Save is disabled. The user has to retype everything from the row.

Root cause (from the shipped bundle public/assets/index-*.js)

The makeStatic action does:

CY1 = n => e => new Promise(t => {
  const r = e(KDn(null));                     // dialog lease = null (add mode)
  setTimeout(() => {
    const i = [
      e(ZDn()),                                // open dialog
      e(k_(zU, "serverName", fd(pTe, n))),     // redux-form autofill
      e(k_(zU, "ipAddress",  fd(nWn, n))),
      e(k_(zU, "macAddress", fd(eWn, n))),
      e(Eoi(zU, "leaseId", "ipAddress", "macAddress"))
    ];
    t([r].concat(i));
  });
});

and the lease form (leaseAddEditForm) does:

componentDidMount() {
  const { lease: e } = this.props;
  this.props.initialize({
    serverName: zr(null, pTe, e), leaseId: zr(null, uTe, e),
    ipAddress:  zr(null, nWn, e), macAddress: zr(null, eWn, e)
  });
}

The app is mounted with React 18 createRoot, so the store update from ZDn() is batched and the dialog (and the form inside it, which is unmounted while the dialog is closed) only renders after the whole setTimeout callback has run. By then the three autofill actions have already written the values into the redux-form state; the form then mounts, componentDidMount calls initialize() with lease = null, and redux-form's INITIALIZE reducer replaces values with the new (empty) initial values. Result: empty dialog. This is deterministic – it does not depend on browser or timing.

The same action/form code is present in the 3.0.151 and 2.4.220 bundles, so this is not a 3.0.159 regression; the ordering assumption (dialog renders synchronously before the autofills) is what stopped holding.

Fix (verified on a live 3.0.159 instance)

Minimal: let the autofilled values survive the initialize:

this.props.initialize({ ... }, false, { keepValues: true });

Cleaner: don't race the mount at all – put the lease data into the dialog state when opening (e.g. KDn({ serverName, address, mac }) with an explicit "create" flag instead of null), so componentDidMount initializes from it and no setTimeout is needed.

Suggestion while you're there

Prefill Lease ID from the lease hostname when it passes the field's own validation (^[\w\-.]+$), e.g. by replacing whitespace/invalid characters with -. Most hostnames are valid IDs and it saves retyping.

Workaround for other users until it's fixed

Type the four fields by hand from the row (select the server explicitly – the preselected one is just the first in the list), or create the static mapping on the router itself (Services → DHCP Server → View Leases → Map Static IP), or via the API: POST /nms/api/v2.1/devices/erouters/{deviceId}/dhcp/leases with {"serverName","leaseId","address","mac"}.

How do I do that? There has to be a way to do it apart from starting all over with a new site/location (including spending hours on fixing the topology when third party equipment is involved and losing all statistics)!

My self-hosted UISP refuses to update M5 CPEs. This applies to both M5 CPEs connected to AC sectors AND M5 sectors. AC CPEs connected to AC sectors work without an issue. In the update tab it simply says "Same version as AP", however it is not same (for example CPE x.6 while AP is x.24). Attaching a screen of an example.

While I don't have a lot of M5 devices, so manual upgrading wouldn't take a huge load of time, I'd obviously still prefer for them to take place automatically during the night.

I'm not sure whether this is an issue or my end or an issue in the UISP application, so I'd love to hear some information about this.

Found a bug in customer service reactivation.

When an expired or ended service is reactivated, the service does not reactivate successfully. The issue is related to the discount start and end dates.

For the reactivation to work, the discount start date and end date must either be set to the current date, a future date, or left unset entirely. If the dates are set to a past date, the reactivation fails.

Even when “No Discount” is selected, the system still picks up and validates the discount dates, which causes the reactivation to fail.

During the reactivation process, no error message is displayed. Instead, the page simply loops back to the reactivation page, giving no indication of what went wrong.

The underlying error and actual cause of the issue can only be viewed through the browser's Developer Mode/Developer Tools. There is no visible error presented in the application itself.

Version: 3.0.159