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
Quote from: nero355 on Today at 12:15:37 AMI 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.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 ?!
Quote from: meyergru on Today at 12:44:25 AMNormally, that would be a scenario for VLANs and different subnets, not ranges.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.
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.
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.
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
Quote from: BrandyWine on Today at 04:59:38 AMQuote 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 ?