"Recent posts
#1
26.1 Series / Re: Potential issue with renam...
Last post by OPNenthu - Today at 08:41:25 PMI added my diff to the ticket as well. The src/dest values in the rules are not getting updated correctly in my case.
I feel that this is impactful enough (though not sure how many will run into it) that it should be considered for inclusion in a hotfix?
I feel that this is impactful enough (though not sure how many will run into it) that it should be considered for inclusion in a hotfix?
#2
26.1 Series / Pointers on how to manually de...
Last post by allenlook - Today at 08:39:33 PMRunning the update generates a message that you should manually delete the dhcpd user and group, but they aren't normal entities apparently.
Does anyone have a pointer on docs to do this?
Google-fu doesn't help much, it doesn't understand the context, and Brave isn't much better.
***GOT REQUEST TO REMOVE***
os-isc-dhcp: 1.0_3
isc-dhcp44-server: 4.4.3P1_2
==> You should manually remove the "dhcpd" user
==> You should manually remove the "dhcpd" group
***DONE***
Does anyone have a pointer on docs to do this?
Google-fu doesn't help much, it doesn't understand the context, and Brave isn't much better.
***GOT REQUEST TO REMOVE***
os-isc-dhcp: 1.0_3
isc-dhcp44-server: 4.4.3P1_2
==> You should manually remove the "dhcpd" user
==> You should manually remove the "dhcpd" group
***DONE***
#3
26.1 Series / Re: Track Interface with 26.1
Last post by franco - Today at 08:33:27 PM> - ISC plug-in issues during future upgrades.
Unlikely. The most critical transition is from 25.7.11 to 26.1. After that the required ISC-DHCP files will remain on the disk without further intervention. Normal erratic behaviour always applies but that's from other factors.
> - A lot of misunderstanding about Track Interface vs. Identity Association and when to use which or why they both exist.
We have time now to update the documentation as the situation evolves and people ask the same questions and 5 months to figure out the next steps before anything changes. That's also why we opted for a maintenance free update regarding ISC DHCP functionality: add new features only and make sure they work as expected before removing other things.
> And minimize the amount of support needed for all of the above ?!
We're in the minimized version of the transition I hope.
> In my case I was kind of expecting things to go wrong with the ISC-DHCP plugin
That wasn't the goal here. Maybe it wasn't clear. Yet ISC-DHCP is the Sword of Damocles in this situation which could fall any second due to security related incidents. We don't know, we don't expect it but it could always happen. Now all the tools for migration are there. If you have to use them that's a different question. Personally, I still use ISC-DHCP for IPv4 and IPv6.
> (Sorry for showing a bit of lack of trust... LOL!)
Why not. It's probably the smarter approach. :)
Cheers,
Franco
Unlikely. The most critical transition is from 25.7.11 to 26.1. After that the required ISC-DHCP files will remain on the disk without further intervention. Normal erratic behaviour always applies but that's from other factors.
> - A lot of misunderstanding about Track Interface vs. Identity Association and when to use which or why they both exist.
We have time now to update the documentation as the situation evolves and people ask the same questions and 5 months to figure out the next steps before anything changes. That's also why we opted for a maintenance free update regarding ISC DHCP functionality: add new features only and make sure they work as expected before removing other things.
> And minimize the amount of support needed for all of the above ?!
We're in the minimized version of the transition I hope.
> In my case I was kind of expecting things to go wrong with the ISC-DHCP plugin
That wasn't the goal here. Maybe it wasn't clear. Yet ISC-DHCP is the Sword of Damocles in this situation which could fall any second due to security related incidents. We don't know, we don't expect it but it could always happen. Now all the tools for migration are there. If you have to use them that's a different question. Personally, I still use ISC-DHCP for IPv4 and IPv6.
> (Sorry for showing a bit of lack of trust... LOL!)
Why not. It's probably the smarter approach. :)
Cheers,
Franco
#4
26.1 Series / Re: upgrade from 25.7.11_9 an...
Last post by franco - Today at 08:22:55 PMThere were no upgrading issues related to ISC-DHCP plugin that needed to be fixed. There is, however, a long standing bug in the FreeBSD package manager that can stop at any point in time due to a race condition which will definitely hit the user regarding the final installation of the ISC plugin since it is the last operation in the upgrade, but this is is neither predictable nor prevalent.
26.1.1 will be reachable from 25.7.11 tomorrow after a few more tests.
Cheers,
Franco
26.1.1 will be reachable from 25.7.11 tomorrow after a few more tests.
Cheers,
Franco
#5
26.1 Series / Re: Need to select "Prefer to ...
Last post by franco - Today at 08:12:23 PMJust post your firmware connectivity audit here so we can see :)
Cheers,
Franco
Cheers,
Franco
#6
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by hugo - Today at 08:02:42 PMI'm not really clear if it's expected that 1.0.11 should fix hostwatch filling up disks from the sqlite DB records. I installed 26.1 fresh yesterday, patched up to 26.1_4, which I understand runs hostwatch 1.0.11. hostwatch still filled up my entire disk (~20 GB of disk space used) in under 6 hours.
Our provider (coax/DOCSIS) makes the WAN *extremely* chatty at ~1,200 received ARP requests per second. I've disabled hostwatch to avoid this causing me issues again. Blanket enabling hostwatch by default on host interfaces is really risky to users, imho, unless its disk usage can be constrained.
Our provider (coax/DOCSIS) makes the WAN *extremely* chatty at ~1,200 received ARP requests per second. I've disabled hostwatch to avoid this causing me issues again. Blanket enabling hostwatch by default on host interfaces is really risky to users, imho, unless its disk usage can be constrained.
#7
25.7, 25.10 Series / Re: LAGG with LAN and VLANs
Last post by ole - Today at 07:49:32 PMIf I also set the LAN 192.168.11.0/24 to lagg0, it is no longer possible to connect to OpnSense's API at 192.168.11.1. Even if I configure g1,g2 on the switch as the access port for VLAN ID 1, there is no longer any access. A network scan of the network shows me all devices—except 192.168.11.1.
So what did I not understand or read? The switch treats the LAN as tagged with VLAN ID 1, or is there something else?
So what did I not understand or read? The switch treats the LAN as tagged with VLAN ID 1, or is there something else?
#8
Hardware and Performance / Re: Drowning in (old) hardware...
Last post by OPNenthu - Today at 07:48:20 PMI am referring to this: https://forum.opnsense.org/index.php?topic=41295.0
My latest programming work was in Python and in that environment I would refer to these as multiprocessing and threading, respectively (though earlier Pythons used a GIL so there could be no true concurrency in threading, but still parallelism is achieved).
I don't know what you mean by this:
If I wrote a simple C program with just an infinite control loop, it would peg a single hardware thread if I'm not mistaken?
Quote from: nero355 on Today at 06:57:01 PM- Multi CPU a.k.a. Multi Core Support.
- Single-threaded vs. Multi-threaded Support.
My latest programming work was in Python and in that environment I would refer to these as multiprocessing and threading, respectively (though earlier Pythons used a GIL so there could be no true concurrency in threading, but still parallelism is achieved).
I don't know what you mean by this:
Quotethere are always multiple threads within any application that is just one big single thread,
If I wrote a simple C program with just an infinite control loop, it would peg a single hardware thread if I'm not mistaken?
#9
26.1 Series / Re: [Solved] DNS port forwardi...
Last post by Roberto - Today at 07:34:36 PMQuote from: Patrick M. Hausen on Today at 02:43:10 PMIf "Home" is the name of your interface then "Home address" is all addresses assigned to that interface, not only the "primary" one configured in the interface setup form.
Thanks a lot for the explanation. That's frankly unexpected: I disabled IPv6 and assigned a static IPv4 address to that interface, so I expected this to be a single address. I use it in a few firewall rules and they work as expected.
Is there a way to see the value(s) of "Home address"?
By the way, why is it possible to select it as target address in a forwarding rule if its value is not a single address?
#10
26.1 Series / Re: Need to select "Prefer to ...
Last post by trdeal - Today at 07:28:56 PMThanks for the feedback, however I never had a problem with IPv6 connectivity in 11 years except with pfsense and now Opnsense (same problem with major upgrades), while upgrades within a major release never cause an issue with "Prefer to use IPv4 even if IPv6 available" disabled.
