Messages

Probably a faulty wifi implementation in the air purifier side. Check with the vendor if there are any firmware updates or known workarounds

2Gb ram is not enough for GUI + widgets in the lobby + whatever services/plugins may be running.

As mentioned in the GitHub issue, the temporary workaround requires the following steps:

1) Go to AGH DNS, comment out any upstream servers. Add 127.0.0.1 for unbound

2) Go to Unbound Settings and disable DNSSEC if enabled

3) Go to Unbound Advanced and disable the NSEC and the two Harden... options

4) Set 1.1.1.1 as upstream for Unbound in the DNS over TLS section


Undo the steps above after updating AGH

Try enabling the lists one by one and see which one blows up

I have only AGH and htop from mimugmail repo, and as far as I remember htop was a clean install with no other dependencies...

In any case, thanks for the hint about the dedicated repo. I'll try it over the weekend and see if there are any issues come 26.1.7 if htop is orphaned for a while

I already have version
v0.107.73 installed. But the plugin changelog says

1.16

* Update to 0.107.67

That's expected. Michael only updates AGH once in a while. From that moment onwards you'll rely on the AGH update feature until lightning strikes again

Works like a charm here.

This is weird...for how long exactly is it working without the py311 warning Patrick?


Heard late last week that mongo was fighting python3.13 via Franco — and I'm wondering if Michael's found a solution and only published it for the dedicated AGH repo only——as there could be other python3.13 issues to fix or waiting to be fixed in the full repo (?)

The update check for Adguard Home is no longer working...

Probably a temporary network issue, unrelated to python 3.11.

There's nothing to check for really as long as there's no new release on GitHub

...
upgrade initially hung in GUI but completed cleanly via CLI (pkg update -f, pkg upgrade, reboot).

This is wrong.

There's never been any official OPNsense guidance about running those pkg commands.

Also, this is not Linux. Reboot and Shutdown -r do different things, and you never want to do a reboot in (OPNsense) FreeBSD

>> Can anyone else confirm?


No. A bit slow but working fine. Only finding was hostwatch not on automatic which I wasn't surprised about, easy fix

FWIW I have 4 FWs on RACK since December and all are running fine on FreeBSD14.3/OPNsense25.7/26.1

You still have time to reconsider.

With a vpn, WireGuard or OpenVPN you'd only allow specific users to access the resource. Otherwise the whole of the internet can hammer the nas at will.

Assuming you'd go for WireGuard, you'd create everything that's needed and only send the third party a QR code.

Should there be a breakage of the vpn, the nas data is still accessible without issues.

_IF_ you can have ddns running on the clients to connect then you can simply lock down the wan access to the reverse proxy by creating a rule with source alias < ddns clients >, and then get rid of the token altogether.

Anyway, food for thought. The goal is simpler and more secure, one way or another.



Should there be a faulty nas update that breaks 2FA - you're in a heap of trouble.

You're forgetting a key principle here - KISS

If you have a vpn there's no need to expose anything synology to the internet nor do you need 2FA.

Making sure that the management port is in a trusted vlan is all you need. Everything else way overkill.

Another thing I didn't see mentioned here:

Did you try disabling the auto negotiation on the ports ?

Is the issue reproducible on other ports?

Can you swap igc0 with another port to see if the same drops happen?

If you can confirm the issue on two ports then the next step I'd try after confirming with Deciso would be to update the firmware on one of the ports to 2.31 which is the latest we have publicly available and see if the issue persists.