Recent posts

#1
German - Deutsch / Re: Firewall Regel DNS Server
Last post by $$fire$$ - Today at 10:45:54 AM
OK besten Dank
#2
Intern ist es domain:

https://github.com/opnsense/core/blob/8ae0a6c158d3fc92e055932af676887248b908bf/src/opnsense/mvc/app/models/OPNsense/Base/FieldTypes/PortField.php#L48

root@opn-dev-02:# cat /etc/services | grep -i "53"
# Dynamic and/or Private Ports are those from 49152 through 65535.
domain 53/tcp    #Domain Name Server
domain 53/udp    #Domain Name Server

Ich kann mich nicht daran erinnern das da mal DNS stand, aber vielleicht erinnere ich mich auch falsch.

#3
German - Deutsch / Re: Firewall Regel DNS Server
Last post by $$fire$$ - Today at 10:35:37 AM
Ah Ok vielen Dank für die schnelle Antwort
Ich war grad ein bischen verwirrt,weil sonst stande da DNS oder?
#4
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

53   Yes         Domain Name System (DNS)[39][11]

Alles gut, Domain ist nur eine andere Abkürzung für das selbe.

#5
German - Deutsch / Firewall Regel DNS Server
Last post by $$fire$$ - Today at 10:23:08 AM
hallo

Ich habe schon lage keine Regel mehr erstellt,aber mir ist das was aufgefallen was sonst nicht so war.
Wenn ich eine Firewall Regel zu meinem DNS Server erstellen möchte kommt zwar das Port 53,aber es steht nicht DNS sondern Domain (siehe Screenshot)
Kann mir jemand was dazu sagen und habe ich einen Denkfehler?
#6
26.1, 26,4 Series / Re: Can I steer hosts to a par...
Last post by endurium - Today at 10:10:29 AM
Quote from: nero355 on Today at 12:15:37 AM
Quote from: endurium on May 20, 2026, 12:41:57 PMIs there a way to "direct" a host to get it's IP address from a specific DNSMasq address pool (DHCP range)?
Can't you just use 'Static DHCP Mappings based on the MAC Address' for those hosts with the specific 'DNS Server IP Address' configured in the mapping ?!
I can do that but I was hoping to leave the selection of the IP address to DNSMasq from a specified address pool/range rather than having to decide on the IP address myself, but it looks to me like there's no point having more than one DHCP range, so I define the desired hosts as static with fixed IPs and tag them, then use DHCP option dns-server[6] to specify the Adguard DNS server address.
#7
26.1, 26,4 Series / Re: Can I steer hosts to a par...
Last post by endurium - Today at 10:00:59 AM
Quote from: meyergru on Today at 12:44:25 AMNormally, that would be a scenario for VLANs and different subnets, not ranges.

When you use static mappings for affected clients, you might as well send a specific DNS server IP with the DHCP option response that is different from the default. So strictly speaking, there does not even have to be a "range" for this purpose.

You're correct, I was trying to avoid specifying an IP address for the static mapping, thinking that by tagging the static mapping it would direct the host to get it's IP from the first pool or range matching that tag, but it just gets it's address from the lowest range.

In ISCv4 I can direct hosts to a particular address pool using MAC address matching so I'd (wrongly) presumed that tags were the DNSMasq way of achieving the same thing.

Which begs the question: what is the point of having more than one DHCP range for an interface?  If I ask Copilot AI, the answer is:
QuoteIn OPNsense's dnsmasq, DHCP ranges exist so dnsmasq can hand out IP addresses — and you can optionally segment those ranges using tags. 
If you don't use tags, the ranges are just "where DHCP leases come from".
If you do use tags, ranges become "pools" that only tagged clients can enter.

But I've found that's not the case.
#8
26.1, 26,4 Series / Re: OPNBEcore 1.8_2 Update wit...
Last post by franco - Today at 09:02:55 AM
The changelog for the plugin is always available from the firmware GUI plugins tab (and it does show the latest changelog before the update is carried out). Typically, minor plugin changes are not pushed to the normal (core-bound) changelogs.

We have some ideas to structure release versioning better in the future. The traditional model of releases isn't working so well anymore with weekly security issues and some reliability fixes especially on the business version.


Cheers,
Franco
#9
Tutorials and FAQs / Re: Guide: Achieving Full IPv6...
Last post by pato - Today at 08:50:24 AM
Thanks for the great guide.
In my case I had to actually enable "Request only an IPv6 prefix" to make it work. Without that it wouldn't, once I checked this and clicked Apply it immediately started to work with the remaining of your settings in the guide.
#10
Quote from: newsense on May 19, 2026, 09:23:40 AMNot every thread warrants a comment

Rest assured the firmware updates will be coming once they're available for FreeBSD

Awesome.

Quote from: BrandyWine on Today at 04:59:38 AM
Quote from: fastboot on May 17, 2026, 07:54:07 AMGood catch regarding the mobile vs desktop R0 variants. You are right, the i3-1215U is a mobile Alder Lake R0 CPU, so .40 should indeed be the correct platform variant, not .80.

So my original assumption about a missing .80 blob was likely wrong.

However, the interesting part still seems to be:

dmesg:
CPU microcode: no matching update found

combined with:

  • installed cpu-microcode-intel package
  • stale-looking revision 0x432
  • newer revisions apparently existing upstream/Linux side

So there still appears to be some kind of matching/loading issue on this platform, even if the root cause is not the missing .80 variant.

I have opened a FreeBSD bug report for further investigation:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

You missed my other point. Did you 100% verify that your device has the exact CPU that is stated on the box, or did they somehow solder in a "desktop" variant.

On the working group page (https://reviews.freebsd.org/D57046), they call out affected cpu families, but the Alder Lake R0 is not named. And, if I am reading it right, it looks like the .40 is not being fixed in any way, but it does look like a fix for the missing .80 is there. So I am still curious.

Also possible, the coders flipped over .40's and .80's, perhaps they mapped the mobile variant to the .80 file and the desktop variant to the .40 file. A possibility that could explain what you are seeing. Or, my info regarding .40 for mobile and .80 for desktop was wrong, but if you go looking you should find same info as I did.

Quote from: meyergru on May 17, 2026, 10:34:36 PMI only happen to know a bit about microcode updates in general. It was obvious that it was a packaging error in FreeBSD, because I happen to have a system based on an i5-1235U from the same family and I know that the current firmware version for that family is 0x43a when updated under Linux.
Your applied ucode is a .80, for a 1235U ?


You are correct that Alder Lake R0 is not explicitly listed in the review text itself, only "and others".

However, the proposed fix is directly linked to PR 295351, which is my report, so upstream FreeBSD at least seems to consider it related.

The fix itself is also fairly generic. It changes how ucode-split handles Intel extended signature tables, rather than adding handling for one specific CPU family.

So at this point I think the more important question is probably not whether the visible primary split file is .40 or .80, but whether the relevant signature/platform combination for this CPU is only present in the extended table and therefore currently ignored by ucode-split.

That would also match the observed symptom quite well:

CPU microcode: no matching update found

So I agree it is not fully proven yet that this specifically fixes Alder Lake R0, but the upstream patch and PR linkage make it look very plausible.