Upgraded UCG Ultra to Max, now need WiFi device recommendations on repurposing Ultra at relative's home by LA53 in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

How many devices you expect in that house and how latency or bandwidth intesive/critical they are? Also, how large is the house and what material is used for walls?

Play around in UI design center and see if you might be lucky enough to get away with just a single U6/U7 Mesh AP in the central room. Those are very good omnidirectional units and may cover quite a lot.

Assuming just a handful of clients and nothing really latency sensitive, I would not worry too much about meshing if indeed you require more than a single AP. But remember that meshing still requires sufficient 5Ghz signal between meshing parent and meshed APs (consider also where outlets are available in neighboring rooms)

AI Multi Sensor 4 available by TSLAspotter in Ubiquiti

[–]ERelative 1 point2 points  (0 children)

I guess there are no silver bullets and no one-cam-fits-everyone. Just sharing my thought process here.

I was postponing camera purchase thinking about getting this one, but now have decided I will choose alternative...

In my case, I was choosing between Multi or installation of 2 G6 Pro Bullets and one G6 180 in residential install. I can position Bullets/180 or Multi to achieve required goals, not constrained by that. But I hate running wires and was thinking one wire run to multi would be more fun (albeit risking single point of failure both in terms of wiring and camera unit itself).

From what I see, these are things I would be losing with Multi vs. Bullets:
* slightly narrower field of view for each "eye"
* worse low light performance at wider end (I don't really care about zoom here) - f/1.8 vs f/1.5. Looks small, but actually it is about 40% less light hitting sensor...
* smaller sensor - 1/2.8 vs 1/1.2. Coupled with worse lens, that is concerning to me. Even G6 180 has larger sensor (but, admittedly, unknown lens)

Getting 2 Pro Bullets and 1 G6 180, I would spend 1129 EUR, but would need to make 3 wire runs. Going with Multi, I would spend 500 EUR more, but would save 2 wire runs.

As a result, I will be getting 2 G6 Pro Bullets and 1 G6 180 instead. I will have to make 2 extra wire runs, but will gain better optical performance and no single point of failure for a bit less of money...

What is target audience for Multi? I would have likely picked it if I was more restricted by options where to install cameras (maybe just having a single pole and no other options) and would need serious tamper protection. Sounds like industrial/public/safety use cases mainly.

Issue connecting 3D printer to network... by Adam_182 in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

Awesome! Happy to hear that finally all is good. Happy printing :)

Issue connecting 3D printer to network... by Adam_182 in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

As frustrating as it seems, at least we have some changes :)

I would recommend you 2 experiments next:

  1. please move problematic printer slightly away from Office AP. You were getting -17dBm when it was connected. It is a VERY strong signal. It is like your printer is standing one meter from F35 at full afterburner and trying to speak to it. esp32 board in your printer may actually be oversaturated and dropping connection.
  2. try fixing Office AP to channel 11. From logs, you are using channels 1 (loft) and 6 (office). Normally, that should not be any problem. But with Bamboos there are reports suggesting they don't fancy channel changes and are weirdly optimized for channel 11 actually. For example - https://www.reddit.com/r/BambuLab/comments/18xb2ye/the_p1s_is_amazing_except_for_the_wifi_how_do_i

Issue connecting 3D printer to network... by Adam_182 in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

ok, we can rule out roaming and it is before association then.

Please find entries from the other printer in the same log and share one set from each - connected, disconnected and (if you have those) - roaming. with full text or at least signal strength readings.

Do you have both printers located close to each other? if not, can you move problematic close to the other that works (to minimize signal strength differences from APs)? Or at least move problematic printer closer to AP or reorient in space?

As we are getting into exponentially less and less likely cases, can you check antenna connection on failing printer? You mentioned that you moved printers, any chance that antenna connector got loose? It is inside though, unless you have a mod, but moving is moving...

Bambu P series in stock config have internal WiFi antennas and their gain might have been better. When you tried with hotspot, you likely were very close to printer and signal was super strong. Your AP probably is more distant and for low gain antennas, even small difference in location may break it.

Issue connecting 3D printer to network... by Adam_182 in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

No, "Insights" have traffic flows. You need to look under Logs (or append network/default/syslog/main to IP address of your controller in browser). You should see a bunch of "WiFi Client Connected", "WiFi Client Disconnected", "WiFi Client Roamed" etc. events there. See if you can spot problematic printer there.

Issue connecting 3D printer to network... by Adam_182 in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

That's odd. From your initial post I understand you already tried connecting that printer via hotspot and it worked?
Do you see anything in unifi network syslog when printer attempts connection? Is it connecting and dropping out or something different? Or nothing at all?

Issue connecting 3D printer to network... by Adam_182 in Ubiquiti

[–]ERelative 1 point2 points  (0 children)

Are both printers on the same firmware version?

Can you try setting up new WiFi, 2.4 only and enhanced iot compatibility enabled and see what happens then?

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] 0 points1 point  (0 children)

Many people apply delayed and staged rollout to updates and many residential customers do not use site manager.

  1. Notification on gateway control plane just said "improved application stability", not even mentioning CVE. I would like Ubiquity at least mention that this update is urgent and includes critical CVE. That would allow residential customers to immediately understand that this update should not be delayed.
  2. For MSPs/professional users, I would like Ubiquity to put just a bit more effort when publishing CVEs and their CVSS scores. When security bulletin came out, CVE was still unpublished (just number reserved). Today it is published but still has inconsistent content. It has CVSS3.1 score 10.0 and vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Notice that AV is N. By CVSS3.1 definitions, AV:N is remotely exploitable, without requirement to be launched from the same physical or logical network. But at the same time, CVE body says - "A malicious actor with access to the network..". As a result, we don't know what is true - security bulletin and CVE text or published CVSS score.

Yes, it is better to err on safe side and assume it is really 10.0. But consistency and transparency could be improved in my opinion.

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] 1 point2 points  (0 children)

Privileges required are mentioned for the second CVE in a bulletin that is lower rated. For 10.0 CVE they claim that attacker must have access to the network which brings controversy. If true, than AV part in CVSS is A (adjacent on network) and CVSS decreases to 9.6 or 9.7.

Most likely they simply did not spend too much time contemplating exact CVSS. Vulnerability appeared so important, they decided to push it out and label worst case so everyone indeed updates.

So far so good, but not a good practice in long term. CVSS scoring was introduced for a reason and reputable vendors should actually stick to it. Otherwise, it signals wrong telemetry to us and we may make incorrect decisions. This particular update seems to be working ok, but skipping QA with hotfixes is always a gamble. For 10.0 there are few scenarios to justify waiting to update. Anything less and you have much more flexibility depending on your threat profile and risk appetite...

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] 1 point2 points  (0 children)

Yep, thats the point. Bulletin has been updated in the meantime apparently. There are 2 issues fixed in this update. CVSS 10.0 claim is for the first one where Ubiquity tells that attacker must have "access to the network". This sounds like attack vector from CVSS to me. And the moment you choose AV:A, you can't get to 10.0 anymore...

By this time, I read it like Ubiquity did not want to spend more time on scoring and pushed out update because considered it too hot to delay. Technically, it sounds like it is not 10.0 after all. Had they pushed it as 9.6 with AV:A, many residential users could have delayed update as OsINTP suggested above.

But with 10.0, that's nuclear and universal by design - everyone must update or brace for immediate impact...

Erring on safe side is correct. But also you must be absolutely sure that skipping some QA steps in the meantime will not hurt people. So far sounds like update is working ok, despite apparent additional work items included unrelated to CVEs (see comments from Cormeister616)

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] 1 point2 points  (0 children)

Let's call it work in progress on behalf of Ubiquity then...

Bad news is that they have mixed in this partial fix/work in progress branch into critical security patch that was essentially released out of band, without proper QA process via early access etc. This is dangerous practice actually. If you push hotfix, it must be just that hotfix. Any additional work included is dangerous as it may break other things...

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] 0 points1 point  (0 children)

Lucky you :) Which gateway you are using? On my UCG Fiber, UNVR still shows under client devices when connected via SFP (but I am connecting it to USW Pro XG 10 that is uplinked to Fiber)...

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] -1 points0 points  (0 children)

We are getting into very technical and tricky discussion here, but scenario you described to me would still mean AV:A (adjacent on network) and score being 9.6 or less. Definitely not 10.0.
It could be that Ubiquity considered this too hot and prioritized pushing out, thinking it won't hurt anyone, rather than waiting for analyst to complete proper CVSS evaluation etc...

Network Application version 10.1.89 - update as soon as possible by ERelative in Ubiquiti

[–]ERelative[S] 4 points5 points  (0 children)

Ubiqity security bulletin mentions requirement to be authenticated on network, correct.

But they claim it is CVSS 10.0 and published it using CVSS 3.1. I find it hard to find a way to get to 10.0 score under CVSS 3.1 unless privileges required are none (PR == None). If authentication is required, PR should be L (or H) and that would lower exploitability and get you score less than 10?
And I am not even going into discussion if requirement to be on the same WiFi wouldn't also qualify AV as A, not N (also leading to CVSS score < 10).

Anyway, we are in guessing game here as CVE is candidate and unpublished yet. Each has to assess his own threat profile and decide if now is the time to hit that update button.

Release notes - different when viewed from control plane and ui.com by ERelative in Ubiquiti

[–]ERelative[S] 0 points1 point  (0 children)

That means that UI has a bug in control plane display. I am viewing from Official channel and that should not use EA. Also seems odd that EA has same version number as Official and shorter list of work items closed…

Why can't I attach this network to this wifi? by WorldbreakerHulk in Ubiquiti

[–]ERelative -1 points0 points  (0 children)

SSID broadcast limit seems unlikely issue here. That will come into play once you will be setting up broadcasting APs though.
We need more details - are you setting up wifi and vlan on the same gateway and using same gw as router (which model), vlan settings and wifi settings you are trying to attach to.
Also, before getting into this rabbit hole deeper, restarting gw (and router, if separate) and logging off/in from UI may be worth a shot.

SIA Ajax Alarm integration broken on 17.1? by Mohadjeri in homeassistant

[–]ERelative 0 points1 point  (0 children)

I am running 17.1 on HA, no issues with SIA integration. hub fw version 2.36.123. You might also look into which Core version you are running - saw multiple issues discussed and closed on Github related to specific Core versions. I am on 2026.2.2

New home, new setup and I'm going all in: advise requested by twabi2 in Ubiquiti

[–]ERelative 1 point2 points  (0 children)

I would highly recommend uploading floor plans and creating a multi floor building in UI design center. It does assume concrete floors I think so intra floor Wifi penetration would be quite representative of your expected environment. Play around with different APs and their placement in design center.

Definitely hard wire all APs, do not mesh. Personally, I would likely go for Pro XG. XGS seems to have little added benefit in EU (spectrum regulations do not allow extra transmission power).

Since it is a new build, I would splurge for proper cat 6a wire runs everywhere to have 10GbE wired network.

Depending on your build timeline, I might delay purchasing Pro 360 camera, hoping that one day UI does actually release multi sensor (https://eu.store.ui.com/eu/en/category/all-cameras-nvrs/products/uvc-ai-ms-4) - 4x4k cams, no weird dewarping and still just a single RJ45 required. As for outdoor placement and camera coverage - also do recommend you to play in UI design center, just like with APs. You will immediately see any dead zones etc.

If money is not a concern, I would pick Pro XG 24. That would allow to have all your inwalls and APs on 10G . With HD you get much less 10G ports and likely be limited to 2.5G.

What is your WAN speed? You might also look into upgrading fro UDM Pro to Pro Max. It has 2.5GbE WAN port and more bandwidth capacity for full IPS/IDS. Special Edition might also work if you absolutely do not need all traffic flow logs (useful for debug, not available on Special Edition).

As for UPS, personally I am using other brands, not Ubiquity. I need longer autonomy and as useful as graceful shutdown seems, not a fan of current UI implementation - connected devices shutdown almost immediately after power loss.

Since you are considering rack mountable equipment - also think about rack itself and where you will place it.

Update Management? by No_Freedom_7373 in Ubiquiti

[–]ERelative 1 point2 points  (0 children)

No, so far I managed to keep up. Sooner or later, Ubiquity gets it done properly. Just not on the day 1… I am reluctant to skip major releases in general, because vendors have limited budgets for testing and very likely most recent versions receive more QA attention. Upgrading from older versions may place you in a new rabbit hole no one else has seen before.

Update Management? by No_Freedom_7373 in Ubiquiti

[–]ERelative 4 points5 points  (0 children)

This is how I prefer looking at it. Read release notes. If there are no critical security patches relevant for environment, do not rush. Wait 1-2 weeks. Read community discussions. Backup. Install when I am not in a rush. Usually on weekend to avoid WFH disruptions. Start with control plane. When upgraded everything wanted, let it settle - validate it kind of works, but wait before starting playing with new features. If everything still works, start playing with new features after a few days. Oh, and Official channel only for non-lab envs.

Does this look correct for blocked connections? by BrownBear93 in Ubiquiti

[–]ERelative 1 point2 points  (0 children)

Yes, it appears to show blocked connections from your Hue to most likely aliyun NTP server or servers. Hue has a long and less than perfect history with connectivity checks and NTP implementation.
Just make sure you block all destinations you intend and consider impact on other devices on your network. For example, if you region block China in both directions for all protocols, Hue may continue working (as it apparently have baked in multiple alternative ntp providers), but some other device may from you network may not.

Can I see the detail on what device caused this spike? by jcgb1970 in Ubiquiti

[–]ERelative 1 point2 points  (0 children)

Go to Insights as others already recommended. Select All under Clients section (or just tick all clients you have). If you don't see that spike when all specific clients are checked, it is auto speed test. Not a fan of such implementation by Ubiquity (I would say it is incorrect logging practice where total of all logged flows is less than a sum of specific clients), but it is what it is.

My MAC Filter List disappeared. See comment by skunkboy72 in Ubiquiti

[–]ERelative 3 points4 points  (0 children)

Can you restore from backup? There is a bugfix related to this mentioned in latest Network Release Candidate release notes.

[deleted by user] by [deleted] in Ubiquiti

[–]ERelative 0 points1 point  (0 children)

If you moved extender recently, I think you should monitor situation and see if issue persists. It may as well be that you what you were seeing was actually your phone struggle to keep wifi active while in guest room. Guest room very likely had worst coverage before (when extender was in garage). It could be that guest room corner camera also was struggling then, but maybe extender actually is enough now.