Recent posts

#1

Hardware and Performance / Re: "Intel CPU microcode updat...

Last post by drosophila - Today at 04:15:48 AM

I see, either way makes sense. It seems like I could implant the CPU type in the PLUGIN_VARIANT variable by deducing it from dmesg output, but that would probably be brittle, even if it can run early enough.

#2

Hardware and Performance / Re: Hardware sizing: Is a 345W...

Last post by drosophila - Today at 03:01:03 AM

Taxes = vaporized (yet somehow still alive and aware), but hey, those are inevitable.

That's because you are paying the taxes that the likes of Musk, Zuckerberg and Trump do not pay.

[0b]

#3

Development and Code Review / Re: What is the status of KEA ...

Last post by drosophila - Today at 02:48:01 AM

After looking at some packet dumps it seems like there are at least two methods of sending the boot file name. Obviously, KEA and udhcpd use different ones, apart from ordering packet options differently.
KEA sends: ... 43 0b 2f 70 78 65 6c 69 6e 75 78 2e 30 ff 63 ...
which translates to "/pxelinux.0" but as you can see, there is an "ff" at the end. This is not a null-terminated string, instead the string length is prefixed, "0b" (decimal 11) in this case.
The decoded packet reads:

Code Select Expand

e.e.e.e.67 > 255.255.255.255.68:  xid:<censored> flags:0x8000 Y:c.c.c.c S:b.b.b.b ether <censored> vend-rfc1048
DHCP:OFFER SM:255.240.0.0 DG:g.g.g.g NS:e.e.e.e DN:"local" LT:3116 SID:e.e.e.e BF:"/pxelinux.0" (DF) [tos 0x10]
udhcpd sends: ... 00 00 2f 70 78 65 6c 69 6e 75 78 2e 30 00 00 ...
which, again, translates to "/pxelinux.0" but is surrounded by all zeros so it is, intentionally or not, a null-terminated string.
The decoded packet reads:

Code Select Expand

e.e.e.e.67 > 255.255.255.255.68:  xid:<censored> flags:0x8000 Y:c.c.c.c S:b.b.b.b ether <censored> sname "<censored>" file "/pxelinux.0" vend-rfc1048
DHCP:OFFER SID:e.e.e.e LT:864000 SM:255.240.0.0 DG:g.g.g.g NS:e.e.e.e DN:"local"

So while KEA passes the filename in a "BF" parameter, udhcpd supplies it in a "file" parameter.

So, given the correct string length passed by KEA it seems like the bug is in the nVidia boot agent, which, of course, is the worst possible outcome because that means that these will never work with KEA.
I might find a way to make KEA send a "file" parameter instead of the "BF", hoping that it will also surround it by zeros or that it will just be implemented properly. More likely I'll ditch KEA for Dnsmasq because naturally I want a solution that works in all cases. The only upside of this is that now I know it.

Would it be an option to have a dedicated PXE Boot VLAN on your network ?

In the past I have worked for a company that had this and the software doing the PXE Boot stuff was some kind of dedicated Linux distro at the time.
So in this case OPNsense would be just the Router providing internet access for all those NetBoot images :)

That would be an excellent option for actual thin clients, as this kind of boot is quite insecure and should ideally be confined even on the LAN.
However, I use PXE for all sorts of things except thin clients. :) (my infrastructure is not robust enough; to depend on it, I'd need HA first) Like initial / post-modification memtest86+ tests and serving the OS installers (debian netinstall), and that can potentially be every machine (except the TFTP server itself, of course). That way, I don't have to fiddle with USB sticks and can apply the same procedure to other peoples machines if need be. :) That's why I need it to "always work", as the type of client is not forseeable. One thing I still need to figure out is how to chainload the BSD bootloader from pxelinux (which provides the menu). Is there some sort of "GRUB" for PXE?

[The mdns-bridge running on OPNsense reflects that message from VLAN 40 to VLAN 20.]

#4

General Discussion / Re: How do IPv6 Router Adverti...

Last post by barney - Today at 01:45:38 AM

This is where I don't understand what you're looking for.

I'm not looking for anything any more - my stuff is all working. I'm continuing the discussion trying to answer questions and maybe explain my setup in case it helps anyone else in the future, and happy to keep doing that if it is useful.

As I understand the situation I have 3 separate networks involved:

• VLAN 20 - fdb4:66c9:5838:20::/64 - containing the OpenHab server.
• VLAN 40 - fdb4:66c9:5838:40::/64 - containing the Dirigera TBR and other direct ethernet / WiFi IoT Devices.
• Thread - fd2c:d79a:65f9:1::/64 - Thread Mesh-Local network containing the Matter devices.

 
These are all separate networks and require L3 routing for traffic to move between them.

The communications I need to happen are:

• Discovery (3 -> 1): devices on the Thread network need to be discoverable from the OpenHab server.
• Control (1 -> 3): The OpenHab server needs to send messages to the devices on the Thread network.

For the Discovery stage:

• The Thread device registers itself with the Dirigera TBR.
• The Dirigera broadcasts an mDNS message, which includes the Mesh-Local IPv6 address of the device.
• The mdns-bridge running on OPNsense reflects that message from VLAN 40 to VLAN 20.
• The OpenHab server gets the mDNS message and registers a device with its Mesh-Local IPv6 address.

For the Control stage:

• The OpenHab server sends a message to the device's Mesh-Local IPv6 address.
• The OPNsense gateway / static route sends this to the Dirigera TBR.
• The Dirigera TBR routes this to the end device.

So the two highlighted steps (Discovery 3, Control 2) are the ones I needed to add.

If my OpenHab server itself was in VLAN 40 then I would not need anything extra - the Router Advertisement the Dirigera publishes would suffice (Note: this is an assumption - I've not tried putting OpenHab on the IoT VLAN so don't know for sure).

When I initially asked this question my thinking was that I needed to get the RA published on VLAN 40 across to VLAN 20 somehow and that would complete the route for the control messages. However, creating the gateway / static route was the actual solution, and it is all working exactly how I want it now.

Final note is that the IKEA Dirigera operates both as a Matter Bridge and as a Thread Border Router. I am only using it as a TBR. If you are using it as a Matter Bridge then the OpenHab server only ever needs to talk to the Dirigera - never directly to the devices on the Thread network.

#5

Russian - Русский / Re: Натройка Sing-box+TUN (про...

Last post by _tribal_ - Today at 01:37:20 AM

а чем они ещё вкрячиваются ?))

например, использую штатные средства опнсенсе а не прямое редактирование конфига?

#6

Russian - Русский / Re: os-xray — плагин Xray-core...

Last post by _tribal_ - Today at 01:34:47 AM

Гдеж ты раньше то был??

так у китайцев минимум год как есть сборка.. там правда упор на Clash сделан.. удобнее он им да и правила роутинга можно писать прямо в интерфейсе.

#7

26.1, 26,4 Series / Re: Port Forward / Destination...

Last post by e97 - Today at 01:25:14 AM

I was able to create a single port forward, but how do I do a range?

The same way, but it seems someone made a typo at the Destination Port field : It should show the same text as the Source Port does ?!

Source Port shows : Single Port or Range
Destination Port shows : Single Port

But in both fields you can enter for example 10000-10100 and there is no error shown or anything at Destination Port so I guess that needs to be looked at by the developers :)

Yes that was confusing. if the Destination Port shows : Single Port or Range and accepts the same value that would remove the confusion.
The docs could also show examples of common use cases which would make this more straightforward and reduce support questions like this.

#8

26.1, 26,4 Series / Re: Constant delay in TLS hand...

Last post by nero355 - Today at 12:13:36 AM

CG-NAT does not handle IPv6

I know, but some providers do CG-NAT IPv4 + Regular IPv6 and the results can be very "mixed" sometimes to say the least...

The last post was not correct. The problem continues. I'll try to disable IPv6 globally to see if that helps.

You can edit previous posts : Either Quick Edit or via MORE... and then the full posts editing option ;)

#9

26.1, 26,4 Series / Re: error message after update...

Last post by nero355 - Today at 12:10:51 AM

i dont understand the error and warning message.

Because things can have delays and/or do not start in the order you would expect them to start so sometimes you get these "timing issues" so to speak...

My logs show this too IIRC but IMHO it's nothing to worry about :)

#10

26.1, 26,4 Series / Re: error message after update...

Last post by allddd - April 24, 2026, 10:13:38 PM

i guess dhcp was just kind of slow?

warning: https://github.com/opnsense/core/blob/3acfb5f2a7d58bdd21f7d5f23e285235853c04d4/src/etc/inc/system.inc#L674-L688

error: https://github.com/opnsense/core/blob/3acfb5f2a7d58bdd21f7d5f23e285235853c04d4/src/etc/inc/system.inc#L703-L723

you later got an ip, /usr/local/etc/rc.newwanip ran and configured everything