Recent posts

#1

General Discussion / Re: The joys of Google AI

Last post by mooh - Today at 03:03:29 PM

So I would invest less in learning one particular new technology, and more in strengthening problem-solving skills: learning how to frame a problem, break it down, question assumptions, move between different levels of abstraction and determine which problem actually needs to be solved.

The current large language models have moved beyond producing output tokens based on stochastic processes and some input. Most LLM interfaces provide insights into the reasoning of the model. They identify unclear questions and ask for input. They also identify sub- problems, ponder about solution strategies and why they choose one over the others, etc. It can be quite amazing, really, sometimes even more interesting than the answer itself.  Problem solving strategies are just another "language".

If I was a young person today I'd probably become a craftsman, assuming that robotics still has 20 years to catch up.

And when I come home after a long day of building the next AI data center I will enjoy the discussions in the OPNsense Science Fiction and Philosophy forum.

#2

26.1, 26,4 Series / Re: Users -> Expiration date

Last post by franco - Today at 03:01:53 PM

Hey,

Thanks for your support!

Here's a simple idea to solve this:

# opnsense-patch https://github.com/opnsense/core/commit/5423ae8fb8c


Cheers,
Franco

#3

Development and Code Review / Re: netflector available as pl...

Last post by UnicronHD - Today at 02:58:27 PM

Without having tried it for lack of need ATM (but will likely arise in the future): does it have a way of restricting discovers reflection to specific (V)LANs, so that, say, the IoT VLAN cannot discover a phone nor TV, while the guest VLAN can see the TV VLAN but not the phones VLAN, but not wake up devices in the server and office VLANs, etc.? Or would that just be set up via conventional firewall rules?

This should work. You would configure several reflector entries. Each reflector entry is unidirectional, so LAN -> IoT lets devices in LAN discover (and wake up) devices in IoT, but not vice-versa. Also, each VLAN pair needs to be configured independently, so there will be no wildcard LAN -> ANY_VLAN things. You explicitly allow discovery between two VLANs in each direction. You could have something like this (each point is a reflector entry with the corresponding protocols enabled):

• LAN -> IoT (mDNS, SSDP)
• LAN -> Cameras (WSD)
• LAN -> Servers (WoL)
• Guest -> IoT (mDNS, SSDP)

This way devices from LAN can discover devices in IoT and Cameras VLANs and wake devices on Servers VLAN. Devices from Guest VLAN can only discover devices in IoT VLAN.

If you need even more control, you could use MAC filters (e.g. to allow devices from LAN to discover TV1 in IoT VLAN and devices from Guest to discover TV2 in the same IoT VLAN).

I hope this answers your question. Let me know if you need any help with the configuration.

#4

General Discussion / Re: IPV6-ICMP "Echo service re...

Last post by proctor - Today at 02:48:41 PM

From the rules page you have to select either-or. But it does have a combined TCP/UDP type, which also are separate protocols, so it's entirely possible that the same is being done silently for ICMP&6. That would certainly be useful, but for clarity there should be a combined setting instead IMO.

Maybe either-or-any and for all of them you have the choice of ICMP and IPV6-ICMP.

#5

General Discussion / Re: IPV6-ICMP "Echo service re...

Last post by proctor - Today at 02:40:23 PM

You can find references to "Echo request" (type 8) and "Echo service request" (type 128) in the FreeBSD ICMP(4) and ICMP6(4) man pages ...

Thanks for the links, you are better than DuckDuckGo.

No results found for "Echo service request"

Suggestions:

    Check spelling
    Try related keywords
    Retry search without quotes: Echo service request

#6

Documentation and Translation / Re: It would appear that FE80:...

Last post by Greelan - Today at 02:10:32 PM

It's already been fixed: https://github.com/opnsense/docs/commit/5c96a70b7bef722e2bd41dce78e1db5bce64be37

#7

General Discussion / Re: VLAN support on bridges fr...

Last post by ArthurK.CICS - Today at 01:15:40 PM

This is definitely freebsd bug territory now as Patrick also suggested:
https://bugs.freebsd.org/bugzilla/

If you have opened one you can also backlink it here:
https://github.com/opnsense/src/issues

Update on the upstream reporting: this was already in FreeBSD's bugzilla — PR 296106
(carp/vlan/bridge: CARP IP not responding on top of bridge),
filed in June against the native 15.x implementation (VLANFILTER bridge, untagged member).
Same signature we saw: interface address on the bridge-vlan works, CARP VIP dead, frames
visible on the bridge but never on the vlan interface.

So instead of filing a duplicate we added our findings there as a comment: the minimal
two-jail repro (entire datapath in-kernel — epairs + vnet jails, no NIC or hypervisor
vswitch touches a frame, which rules out the ESXi theory from earlier in that PR), plus the
code-level cause from reading if_bridge.c: bridge_input()'s GRAB_OUR_PACKETS only consults
the bridge's own if_carp (CARP_CHECK_WE_ARE_DST(bifp)), never the vlan child's, and vlan
demux happens only after a frame is accepted as local — so the vlan child's virtual MAC
always fails the "ours" test and gets flooded instead of delivered.

Notable from that PR: comment #9 confirms it independently and describes an epair-based
workaround (CARP on the b-side of an epair whose a-side is a bridge member, so the virtual
MAC actually gets learned). Hacky, but it exists.

#8

26.7 Series / Re: SSH to opnsense fails afte...

Last post by drosophila - Today at 12:16:02 PM

Looking more closely at the entire log there must be something (ph/f)ishy going on with the connection. The algorithms don't match either, nor does the key format.
(debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
vs.
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512)

Also, the password auth is not in the available methods so it cannot succeed: Mine says:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
the OPs says:
debug1: Authentications that can continue: publickey

MITM attack going on?

#9

General Discussion / Re: The joys of Google AI

Last post by meyergru - Today at 12:00:54 PM

That is an interesting and difficult question - I am grateful I do not have to ponder that out of sheer necessity.

What I see now is that LLMs have some specific advantages over humans. For example, the more capable models can keep a much larger amount of information in their working context at once - something I have found much less useful with smaller local or free models.. They can therefore do tasks "in memory" for which I would need pencil and paper, or several intermediate steps. They can also access information on the Internet much faster than I can.

So I basically use them as tools that can be guided and directed by me - and much more efficiently and cheaply than a team of human assistants ever could.

For people doing intellectual work, I would argue that the important thing is to develop the skills needed to make the best use of these tools. That being said, it still takes a lot of expertise and problem-solving ability to direct them properly - at this point, they still need expert guidance and supervision.
My best guess would be that the gap between good and bad engineers will probably widen. There may be fewer people doing this kind of work, but those who remain in demand will be highly skilled and very productive.

So I would invest less in learning one particular new technology, and more in strengthening problem-solving skills: learning how to frame a problem, break it down, question assumptions, move between different levels of abstraction and determine which problem actually needs to be solved. Domain expertise certainly helps, but these skills transfer remarkably well between domains.

Quite often, the important question is not how to perform a task correctly, but whether it is the right task to perform in the first place. Those decisions should not be left to managers alone, and AI is certainly not suited to making them either.

That is something I have been practising for decades. Story of my life. Even without the AI part.

#10

Development and Code Review / Re: netflector available as pl...

Last post by drosophila - Today at 11:54:14 AM

Without having tried it for lack of need ATM (but will likely arise in the future): does it have a way of restricting discovers reflection to specific (V)LANs, so that, say, the IoT VLAN cannot discover a phone nor TV, while the guest VLAN can see the TV VLAN but not the phones VLAN, but not wake up devices in the server and office VLANs, etc.? Or would that just be set up via conventional firewall rules?