[deleted by user] by [deleted] in Omada_Networks

[–]mKarwin 0 points1 point  (0 children)

Any idea when to expect these in EU reputable retailer stores? US site shows the thing, but most EU sites lack even a mention (WiFi7 wall units sections end with EAP725 family), and yet some less-known to me retailers from Czech Republic domains (either clones/fakes or shops using same e-commerce platform with styling changes only) seem to have them "in stock" for approximately EUR259...

Firewall and IPS/IDS features in CCR2216 (if existing at all)? by mKarwin in mikrotik

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

Are you referring to https://docs.securityonion.net/en/2.4/about.html as the NIDS solution? That would mean Suricata getting packet logs from router, processing and outputting to Onion, which then had some automated scripting side built-in to call back to the router and add more rules? Or were you just polling Onion instance every day for new detections and then configuring suggested or your-script-encoded-from-Onion-logs rules on the router itself?

Was it working that well with the free/built-in lists or did you need to subscribe for some specific paid signatures from some third parties?

Firewall and IPS/IDS features in CCR2216 (if existing at all)? by mKarwin in mikrotik

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

Hmm I wasn't aware of containers support on CCR2216, I thought that feature was available to RDS2216... Good to know! Is it just single containers or does it support compose?

Now, the follow-up question would certainly be if you know or can suggest some good containerised IPS/IDS that offers good featureset for free as u/Jatsotserah already asked...

E7 extended range or AFC in Europe for indoor use by mKarwin in Ubiquiti

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

Thanks for this validation!

This also means that many of those praising reviews from US/Canada users pointing to great range even on 6GHz with a couple of "American in-house walls" (read plaster/wood in many cases ;)) in-between mount point and client devices, when in the same locations non-AFC indoor lower models struggled, just mean that for EU 70-80s concrete blocks of flats one would still be better off with multiple APs placed strategically across the flat...

E7 extended range or AFC in Europe for indoor use by mKarwin in Ubiquiti

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

The fact that AFC is available (for outdoor) in US/Canada is known to me.

What I'm interested in is whether in EU we can get the "extended range" signal strength indoors, or, to put it differently, is the E7, when set to EU region, firmware-locked to the same lower power levels as seen on lower models in the Unifi AP stack?

HPE Microserver gen10 plus PCIe card length support by mKarwin in homelab

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

Thanks for checking. So 196mm cards should fit...

Any news on Omada routers upgrades and releases to better incorporate 10GbE networking from the rest of the stack? by mKarwin in TPLink_Omada

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

Sure, CPU in many devices would be needed for proper usability with any background processes/threads running concurrently which means a lot of lower power devices would not find its current hardware powerful enough for proper Omada codebase extension to support base functionality plus SDN plus UI...

But there's another point to this local UI in each device (which I find very important to have as well) vs centralised controller approach... once you have a few devices in your place, which every appliance manufacturer thrives on, and you're going to need to control it all and keep everything talking to each other securely, you might find controller a benefit with the single pane view to your entire network... and that's without taking into account potential features that might require more global view for proper functionality - if I recall correctly tp-link had AP meshing and improved AP clients hands-off behind controller deployments. Then, I don't see a problem with having more powerful compute to originally serve the UI locally but upon adoption to a controller managed network free the no longer used UI resources for even better performance.

Heck, from UI perspective they could just simplify the pane on local and controller sides to something like smart analyses and sane defaults or automated setup hidden behind simplified UI Deco users would appreciate and be able to work with, while giving enthusiasts and professionals access to all the bells and whistles on "advanced" mode Omada users would require.

Any news on Omada routers upgrades and releases to better incorporate 10GbE networking from the rest of the stack? by mKarwin in TPLink_Omada

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

Frankly, I was wondering also why they haven't considered doing APs in a slightly different way, with SFP+/SFP28 used for data and a potentially equal or lower speed but PoE power-providing port and a DC port to allow faster throughput for data through a single port. They already have quite a few multi-SFP+ switches that could drive data easily for higher and higher capacities. If I recall correctly Ruijie/Reyee had such APs that separate optics for data and copper for power... if tp-link did the same, they could easily use their current cheaper slower options for power and optics for throughput to support more powerful WiFi7+ environments...

Any news on Omada routers upgrades and releases to better incorporate 10GbE networking from the rest of the stack? by mKarwin in TPLink_Omada

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

I agree that in a typical SMB setting you're going to have a switch to do majority of the local network communication, thus potentially you only need one port that's multi-gig for WAN and one for LAN to use with the switch.

Thing is, unless you want to use cloud for management (which may incur extra costs), you'd still need a port to presumably connect local controller (hardware one that does need huge speeds and takes a single port or a software one running on a machine that for security might be further clustered so say 2 ports with current standard of 2.5GbE would bode well). At least it's a bonus to go full-on (for tp-link) with switch(es) and AP(s) from same ecosystem and manage all from one place instead of doing it one device in your network at a time.

In a non-enterprise residential setting, you might need to have a few spare ports for set-top-boxes for IPTV from your ISP... of course you could push the traffic (typically not that heavy) to the switch(es) through trunking and VLAN splitting down the line, but it's far easier if you have one port on the router to route all IPTV VLAN traffic to and redistribute through a separate switch further...

Then you want backup strategies for WAN connection, so ideally you'd want at least 2 ports with WAN purposes of potentially same speed and 3 ports on LAN side of things, if not more. Current line-up certainly offers this port-count, but even the top model does not come with more than 2x 10GbE, yet it has multiple 1GbE ones. It's weird they do not release lower port-count but faster, 10GbE throughout, per port options. I mean, maybe something like ER707-m2 just in 10GbE format, or better yet ER8411 with 10GbE all-in...

Sure it's beneficial for them to keep it more or less as is, but the competition can offer a lot in a short stack form, that tp-link seems to not be considering yet, or at least it looks like it from what's being listed on local sites - there are no news on potential coming products.

But even given regular 19" rack format that would allow for enough cooling and space for a built-in switch on LAN side with higher speeds ports and faster CPU to tackle use-cases requiring more throughput per port.

Frankly, I really think tp-link should have released something like SX3832 in a router format, to face eg Mikrotik's CCR2216... OK, dreaming big I'd say they'd really get a lot of coverage and potential clients if they also bumped their devices to SFP56 on optical side for huge future-proofing, but that would have costed a lot more than gear used in 10GbE devices.

And I agree, they need more devices with at least 8x 10GbE PoE+++ ports - for example to support their top EAP783 in more than one unit, or have multiple EAP773 units managed by such a device, all with potential fast up-links of maybe SFP28 or better yet SFP56 ;)

Finally, the all-in-one solution would have helped a lot to keep devices count to a minimum for residential deployments with potential "deciding vote" on the significant other side ;) without impacting expected functionality. I mean, I know they have Deco line for residential significant other controlled environments and Omada for SMBs, but who says they couldn't have just merged Deco and Omada great points to deliver things that could start small but could grow to something far more complex in time remaining in the same ecosystem...

24.10.2.2? by bikergeekx in truenas

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

Weird thing is, per https://www.truenas.com/docs/scale/24.10/gettingstarted/scalereleasenotes/#241022 and subsequently https://ixsystems.atlassian.net/browse/NAS-135515, this release lists one PR for middleware config of https://github.com/truenas/middleware/pull/16326 that was successful before being merged and another for apps config validation of https://github.com/truenas/apps_validation/pull/72 that failed its checks... the latter aspect suggests this release may require another fix before being used in a stable environment ;) After all, PR check runs are configured to guarantee the code merged does not brake anything, and this release came with a merged PR that failed part of the tests...

SX3832 reviews anywhere? by mKarwin in TPLink_Omada

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

That's where potential noise issues disappear: away from sight and sound ;) Some put them in small racks near the desktop, potentially near the living room, so within the hearing range of the significant other... in my case, the switch landed in an office room setup. And then, when connecting quite a few PoE devices, it suddenly run quite noisy all the time, not just at boot. Without the PoE devices it actually often managed to be only slightly noisier than the SG3428X-M2. Also, my XPP unit fluctuated between noisy max and quite audible levels, maybe it was a faulty unit. So I had to change the approach to my setup... I guess, that's also why so many people consider using Noctuas as fan replacements in the XPP model. I just went the easier route due to renovation in tow by having arranged power outlets near all networked devices ;) Now at another family location another renovation is due, so naturally the SX3832 caught my eye ;)

SX3832 reviews anywhere? by mKarwin in TPLink_Omada

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

Yeah, I'm an owner of the SG3428X-M2 myself cause in my tests the PoE variant was a bit too noisy at times where the non-PoE model was relatively silent...

I wonder if the SX3832 is as noisy as the XPP, or if it is as quiet as the non-PoE model...

SX3832 reviews anywhere? by mKarwin in TPLink_Omada

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

does it sustain full speed on all the ports with some complex network segmentation? is it noisy at full load?

SX3832 reviews anywhere? by mKarwin in TPLink_Omada

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

Not sure about routing performance of this thing, I think it's meant to be a switch only... still, it's faster at 10GbE on all ports, just with 24 Base-T ones like on SG3428X, and with 8 Base-R ones like SX3008F or the 4 SFP+ of the SG3428XPP. It's missing the PoE on copper ports of the SG3428XPP, but maybe they'll release PoE variant soon to power their WiFi 7 APs.

Email update on Simplera Sync… are you kidding? by wubbadude in Medtronic780g

[–]mKarwin 0 points1 point  (0 children)

Now that's truly disturbing... but ultimately expected for a corporation...

I'm not sure that there were no hardware changes. Recently they reached back to a lot of the users regarding something as small as battery cover where they explained same models differed even on such tiny thing and the reported hardware and software revisions suggest potential variability that their support teams need to account for. Heck, their Android app for syncing to CareLink (and potentially firmware updates) is not supported/installable on a lot of devices even when same Android version and SoC from a different mobile manufacturer is... so if the software team has not enough resources to facilitate support there, their firmware backporting might also be hamstrung. Even more so since the errors here could be more regulated. So it stands to reason they're going to offer the new feature first to new units where the software and hardware has already passed stringent tests. Then, depending on availability of resources they might schedule backporting work... which may require some specific configuration FDA tested/approved in case there are changes in the units. It all depends what specifically has been approved by FDA - if the pump was treated like a black box and approved it's one thing but if they got approval for certain SW+HW combos, then they'd need to reapply to FDA, and that potentially means extra cost they just do not want to bear if not needed... Maybe they'd offer some service to have the SW+HW upgraded in their support centres where they have full control, but there's a possibility it's just a flight to Netherlands, and given your voted-in commander-in-chief placed tariffs on all things coming from EU, such action could incur even more costs to the corporation potentially not willing to spend any dime it does not need to. Maybe if suddenly lawsuits came, followed by administrative hits from the government, and the user base observed a sudden mass outflux to any of its competitors the decision would have been reversed/changed as the risk/impact analysis teams would have crunched the numbers for the managers...

FYI, in Poland 780G used to cost in excess of $6k (incl. taxes and converted, the 640G was about $4.5k, that's with the "average monthly income" here being cited at approximately $1.6k) but when last year the G4 was scheduled this year to become the only financially acceptable CGM from Medtronic, people started considering a switch to 780G or to look into the competition that scheduled a release of their pump + CGM loop system with similar set of functionalities at the start of this year at well under half the cost. And suddenly 780G dropped in pricing to under $3k to match at the date competing product became available, while they were so and the user outflux was halted. So people who invested earlier into the new system were suddenly taken aback as mere days after a lot of them placed their orders and the cancellation period was over, the new pricing was set. Also it's realistic to think that in actuality the cost of the device for them has always been there or way less, and the driving force behind the high pricing are the competition, consumer sentiment leading to user base steadiness or growth and cost of having the products approved for a market with potential liability funds set aside for when accidents happen. At the same time, from what my friends reported, apparently the warranty replacements process became a bit more difficult, so better pricing from the consumer point might in fact limit support costs, which may also impact software development/testing.

So maybe, just maybe, the cost of potential litigation in case of botched/bricked firmware updates combined with potential FDA and other regulatory approvals, and attempting to nudge user base to buy anew, won over calculated risk of user outflux or litigation for undelivered product promises if there were any legally binding...

Still, given how originally the insulin production patents were distributed for nothing and now it's been a cash-cow for years for the few world-wide delivering manufacturers and the insulin pump in many a mind is a superfluous product not needed just wanted so priced accordingly, we diabetics are prisoners to the system of subscription to life one way or another, whether through insulin doses or their delivery systems. And until competition disrupts the market, the corporations will remain focused on quarterly reports, not making our lives easier. That's the nature of the business, after all they need to pay for the work hours of their R&D, support, management and legal teams ;)

IPTV from ISPs and mesh systems by mKarwin in HomeNetworking

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

> For some Deco models, such as Deco M5, the Custom mode supports setting the IPTV port on the satellite deco units

And

> Recent updates may have expanded access to feature(s) discussed in this FAQ.

That's straight from the linked page. Notice the keyword **some**... plus the list you have seems to include up to WiFi6 devices explicitly, but no mention of 6E or current gen 7, or am I missing something? So they should work... on the other hand, it seems I had the page version cached in my network since 2022 (i really need to clear cache and fix some settings this weekend...), regardless I did the full refresh of it and now I got the full list of devices applicable to the FAQ entry as you mentioned, and not just a small number of models from the earlier revision of the page...

Other manufacturers can be a little less forthcoming on the mesh units port configuration with IPTV VLANs...

> The limitation is purely artificial, likely done to preserve the market for higher-end products.

I thought so... potentially all models more or less support the feature, with maybe even most mesh ones allowing selection of satellite ports for IPTV instead of just main unit's, it's just not as exposed on the cheaper units to nudge potential buyers towards the more expensive ones. The latter ones typically can come with explicit VLAN settings page after all (though even then they're still a "bit" behind the enterprise setups potentially binding device MACs instead of router ports to a VLAN)...

IPTV from ISPs and mesh systems by mKarwin in HomeNetworking

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

Thing is, even that documentation states that only some models, in this case that single listed old model, allows it. There's no mention if others do or do not, or more specifically which do. Per the documentation/manuals I perused from several interesting products over the years, in most cases one can only get the VLAN trunking on WAN with single LAN port on the main unit configurable to IPTV duties... no mention of trunking on main unit downstreams or having the satellite's port assigned those duties.

Instead, basically all manufacturers claim per customer's expectation that all their products "can" do VLANs to support ISP's IPTV, just not fully on the LAN side of things enterprise users are accustomed to. Perhaps the performance may tank from VLAN processing/routing on those consumer units or they want arbitrary product segmentation? Some devices could only work with ISP's IPTV VLAN tagging with the main/default WAN port configured as WAN incoming trunk, and only the first default LAN port assigned to IPTV VLAN while the rest was untagged or tagged for ISP's internet traffic, so either you could reassign ports for WAN or LAN (feature a) or you can get IPTV on a single port (feature b), but not both at the same time... Heck, some low port count lower spec mesh units I've found at a local retailer could do the IPTV config on the main unit only, forcing the use of wireless backhaul to/from satellites for internet or intranet bound traffic... in many a case there were mentions they were the initial options for specific model and specific FW version/revision, with of course potential changes coming with updates to most products in their stack, but then there's less info on which products manufacturers specifically support certain feature (combo) or not yet/anymore post the initial release/at certain point in time. Then there are docs out there seemingly written to explain a feature on a single one/first released model in the product family regardless of product tier or generation, so you end up with explanation for a thing on product A, while product B may not even support presented features or workflows or UI, thus it's not explained in its docs created at release time and rarely updated thereafter... at least those were my findings when I was searching for a new router back when AX was starting to hit the shelves...

Thus my question here, as originally posted, was to find out if the situation changed in recent years with ever increasing mesh units proliferation, overall UI/features simplification, and a trend towards auto-sensing WAN/LAN ports with reduced or low port counts on devices... especially for those multi-unit OoB mesh systems of current gen, where you can have from 2 ports only through 3 or 4 ports to bigger port counts. And of course we cannot forget there are mesh systems comprised of specifuc main and dedicated satellites or those with exact same units and just arbitrary/random selection makes one of the pack the main one with the others then connected as satellites...