Recent posts

#1
26.1, 26,4 Series / Re: Cron scheduled missing?
Last post by DEC740airp414user - Today at 09:56:33 PM
I should create my posts while I am in front of the console.   Yes Cron is where you said but

  My full reason for the post is seeing scheduled jobs under system.   It can do similar but with less instructions?

I still have an ids rule I can't delete under Cron from a year ago. 

Which should be used going forward



#2
26.7 Series / Re: Fetching base-26.7.3-amd64...
Last post by nerd - Today at 09:09:16 PM
Nobody has an idea?
#3
German - Deutsch / Re: SSD Killer gesucht
Last post by stulpinger - Today at 08:30:46 PM
Zenarmor am Laufen ?
#4
26.7 Series / Re: Lenovo M720q randomly hang...
Last post by Patrick M. Hausen - Today at 07:57:39 PM
We need to fix that bug in the boot loader. I am quite a bit disappointed the issue in the tracker has not got any attention. In March a volunteer intending to fix the problem asked for some information - no response so far.

I'll raise some "management attention" in a week ;-)

Kind regards,
Patrick
#5
26.7 Series / Re: Lenovo M720q randomly hang...
Last post by userunkn4wn - Today at 07:38:19 PM
Quote from: Patrick M. Hausen on Today at 04:35:21 PMDid you try setting the primary console to serial and the secondary to none as I already advised?

Yes, I tried that setting as suggested, but unfortunately, it didn't solve the issue. I suspect this workaround only applies when the system fails to boot altogether. In my case, it's just inconsistent, it boots fine about 3 out of 4 times, but occasionally gets stuck.

That makes it really difficult to isolate the cause, as the behavior is fairly stochastic. Sometimes it works 5 to 6 times in a row, leading me to believe it's fixed, only for it to fail on the next attempt. It's tough to troubleshoot under these conditions.
#6
26.7 Series / GeoIP updater repeatedly hits ...
Last post by almapavi - Today at 07:28:46 PM
I investigated this further and I believe I have identified the sequence causing the MaxMind daily download limit to be reached.

OPNsense version:
OPNsense 26.7.3_8 (amd64)

The GeoIP database itself was present and appeared healthy:

/usr/local/sh
are/GeoIP/alias.stats
/usr/local/share/GeoIP/alias/NL-IPv4
...other country files...

NL-IPv4:

size=308932 bytes
modified=2026-08-30 13:50:03

The issue started approximately 24 hours later, when the GeoIP database became eligible for refresh.

The first GeoIP error was not a MaxMind quota error. It was:

geoip update failed :
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>
The request signature we calculated does not match the signature you provided.
Check your secret access key and signing method.
</Message>
...
</Error>
[http_code: 403]

The failed request was against MaxMind's redirected Cloudflare R2/S3-compatible storage URL.

After this initial 403 SignatureDoesNotMatch, OPNsense started making GeoIP download requests extremely rapidly. MaxMind's download history showed close to one request per second.

Shortly afterward, OPNsense started reporting:

geoip update failed :
Daily GeoIP database download limit reached
[http_code: 429]

There were many of these within only a few seconds.

For example:

2026-08-31T13:51:50  HTTP 429
2026-08-31T13:51:50  HTTP 429
2026-08-31T13:51:51  HTTP 429
2026-08-31T13:51:51  HTTP 429
2026-08-31T13:51:52  HTTP 429
2026-08-31T13:51:52  HTTP 429
2026-08-31T13:51:53  HTTP 429
...

This does not appear to be caused by an aggressive GeoIP cron schedule.

The firewall also has normal hostname aliases that resolve periodically, for example:

resolving 2 hostnames for stats_reportcpanel_com
resolving 2 hostnames for ai_reportcpanel_com
resolving 3 hostnames for AllowList

These run approximately every six minutes.

Based on the GeoIP code behavior, the likely sequence appears to be:

GeoIP database becomes older than ~24 hours
        ↓
OPNsense determines GeoIP update is required
        ↓
MaxMind download attempted
        ↓
Download fails with HTTP 403 SignatureDoesNotMatch
        ↓
Existing NL-IPv4 file remains older than 24 hours
        ↓
Next GeoIP lookup still determines that an update is required
        ↓
Another MaxMind download is attempted immediately
        ↓
Failure
        ↓
Another GeoIP lookup
        ↓
Another download
        ↓
...
        ↓
MaxMind download quota exhausted
        ↓
HTTP 429

The important issue appears to be that there is no effective retry delay/backoff after a failed GeoIP download.

A temporary upstream failure therefore causes every subsequent GeoIP lookup/update operation to attempt another complete database download.

That explains why a single failed daily refresh resulted in dozens of MaxMind requests in a very short period.

As a temporary workaround, I updated the modification timestamp of the existing valid GeoIP sentinel file:

touch /usr/local/share/GeoIP/alias/NL-IPv4

This does not change the GeoIP ranges themselves, but it prevents OPNsense from considering the existing database stale and repeatedly attempting another download until the MaxMind quota clears.

It would probably be beneficial for the GeoIP updater to implement something such as:

Failed GeoIP update
        ↓
record last attempt time
        ↓
do not retry for X minutes/hours

or otherwise ensure that only one GeoIP database download attempt can occur during a single alias-update process.

A temporary MaxMind/provider failure should ideally generate one error and continue using the existing GeoIP database rather than repeatedly downloading until the account rate limit is reached.

At this point the evidence suggests:

The existing GeoIP database was valid.
The normal ~24-hour refresh became due.
The initial MaxMind/R2 download failed with 403 SignatureDoesNotMatch.
OPNsense immediately retried many times.
Those retries exhausted the MaxMind GeoLite daily download allowance.
Subsequent requests returned HTTP 429.

Hopefully this helps reproduce the issue.
#7
26.7 Series / APU1: No network with 26.7.3
Last post by iam - Today at 07:07:09 PM
Hi,

after upgrading to 26.7.3 my APU1 has no network connection. ping fails from inside and outside. The plugin os-realtek-re is installed.

I booted a snapshot with 26.7.2_2 and have a working setup for now.

Any idea what is causing trouble? Maybe the plugin os-realtek-re does not work on 26.7.3?

Best,
Stefan
#8
Thanks both. I completely agree about avoiding a generic "Swiss army knife" with lots of special cases. That wasn't really what I had in mind either.

My suggestion was specifically a dedicated Roon/SOOD reflector, but only if the protocol fits cleanly within Netflector's existing model of explicitly supported discovery protocols such as mDNS, SSDP and WSD.

I mentioned the source-IP and WireGuard/roadwarrior details mainly so that, if Roon support is investigated, the important part of the use case is known from the start. If implementing that would require too many Roon-specific exceptions, keeping a dedicated tool such as udp-proxy-2020 or RoonBroadcastRelay is of course perfectly reasonable.

If it does fit, I'd be happy to test a development version on OPNsense with Roon across a WireGuard roadwarrior connection.
#9
Careful that you don't accumulate too many edge cases and turning it into an unmaintainable swiss army knife without a clear identity.

I know AI helps but long term having less or dedicated tools fits unix philosophy better.

Not saying you cannot add whatever you want though, just saying from some experience. Though everybody should of course make their own experiences.

I think the gist is, define what Netflector is before accepting every discovery protocol it could theoretically support, especially application specific ones you will have to support forever long after the application might have already died.
#10
Quote from: RamSense on Today at 05:46:59 PMWould a dedicated Roon/SOOD reflector like this fit within the scope of Netflector?

Thanks for the idea! From what you are describing it sounds like Roon/SOOD might be a good candidate to support. I will look into it.