"Recent posts
#81
Q-Feeds (Threat intelligence) / Re: Looking for testers Q-Feed...
Last post by netwarden - December 16, 2025, 09:36:34 AMQuoteOh my mistake, yes on the latest version you only need to enable it in our plugin indeed.
Please update the documentation to reflect this. Also, it doesn't seem to be working - I don't see any malicious domains getting blocked in the Unbound logs.
#82
25.7, 25.10 Series / Re: OPNcentral: Provisioning R...
Last post by ews - December 16, 2025, 09:22:52 AMQuick feedback. It works in 25.10.1.
#83
25.7, 25.10 Series / Re: OPNCentral cannot provisio...
Last post by nono - December 16, 2025, 09:20:17 AMI agreed that the fix make it works now.
Thanks !
Thanks !
#84
General Discussion / Re: Lan Interface - VLan 1 - 2...
Last post by Patrick M. Hausen - December 16, 2025, 09:19:32 AMQuote from: spooner.arthur on December 16, 2025, 08:02:42 AMI also need incoming Firewall Rules for the 3CX.
Is that a problem?
No, of course not.
#85
Hardware and Performance / Re: DEC697 vs virtual build / ...
Last post by meyergru - December 16, 2025, 08:45:00 AMWhen you have a longstanding experience, you know how such low-level things work.
I remember that I once wrote a printer buffer for MS-DOS. The machine hardware had a parallel port, which gave you a status of if it can handle the next byte to output. The default implementation of the "print one character" system call was to do a busy wait for a clear status and only then output the character. This was a synchronous process.
Needless to say, that with a non-concurrent OS like MS-DOS, the whole machine was blocked until the print process was finished. The remedy was to use a memory buffer queue and append every character there. In addition to that, there was a timed event that then tried if the status was clear and send as many bytes as it could from the buffer.
That way, if the buffer size was sufficient, you could "print" a job in virtually no time and continue work, while the real printing was done asynchronously in the background. Also, there were much less busy waits, so the overall overhead was reduced.
In reality, a try to send as many bytes as possible was also made at the end of the "print one character" call, but those byte were of course first taken from the buffer in order.
I guess you can see the similarity to net.isr.dispatch = "deferred": With "hybrid", the NIC interrrupt is potentially handled immediately. That way, you get the best of both worlds, because with "deferred", there can be small latencies.
P.S.: I know - "war stories"... ;-)
I remember that I once wrote a printer buffer for MS-DOS. The machine hardware had a parallel port, which gave you a status of if it can handle the next byte to output. The default implementation of the "print one character" system call was to do a busy wait for a clear status and only then output the character. This was a synchronous process.
Needless to say, that with a non-concurrent OS like MS-DOS, the whole machine was blocked until the print process was finished. The remedy was to use a memory buffer queue and append every character there. In addition to that, there was a timed event that then tried if the status was clear and send as many bytes as it could from the buffer.
That way, if the buffer size was sufficient, you could "print" a job in virtually no time and continue work, while the real printing was done asynchronously in the background. Also, there were much less busy waits, so the overall overhead was reduced.
In reality, a try to send as many bytes as possible was also made at the end of the "print one character" call, but those byte were of course first taken from the buffer in order.
I guess you can see the similarity to net.isr.dispatch = "deferred": With "hybrid", the NIC interrrupt is potentially handled immediately. That way, you get the best of both worlds, because with "deferred", there can be small latencies.
P.S.: I know - "war stories"... ;-)
#86
General Discussion / Re: Lan Interface - VLan 1 - 2...
Last post by spooner.arthur - December 16, 2025, 08:02:42 AMThanks for the replies.
I need two Gateway.
1. for the Clients and Servers and so
2. for the 3CX PBX and Phones
I also need incoming Firewall Rules for the 3CX.
Is that a problem?
I need two Gateway.
1. for the Clients and Servers and so
2. for the 3CX PBX and Phones
I also need incoming Firewall Rules for the 3CX.
Is that a problem?
#87
Hardware and Performance / Re: DEC697 vs virtual build / ...
Last post by passeri - December 16, 2025, 07:15:57 AMThank you for the additional explanation, meyergru. From the links I conclude that it is a case of test in your own environment. I had maxthreads and bindthreads set, with dispatch set now. I might re-do the process with testing.
#88
25.7, 25.10 Series / Re: Memory protection faults
Last post by patient0 - December 16, 2025, 06:44:05 AMQuote from: teb on December 16, 2025, 02:27:36 AMThis is on an official OpnSense DEC2750. I am thinking the RAM has gone south, so I was going to order replacement. It looks like it is DDR4, but in what configuration? 2x4GB?I would run a memtest86+ first.
<snip>
Is there something else I should look at?
But if it is memory, is 1x8GB and is very low profile. In my DEC740 was a 4GB Transcend TS512MLH64V6HL (see photo attached, the 'L' is really important) and I replaced it with an 8GB Kingston KVR26N19S8L/8. I guess the 8GB model could use Transcend TS1GLH64V6BL, which is just the 8GB model of the one in mine.
You can use 'dmidecode' to check what RAM you got and there are plenty of threads on this forum about that topic, e.g. https://forum.opnsense.org/index.php?topic=32615.msg157764#msg157764
#89
General Discussion / Re: Can I inststall smokeping ...
Last post by Meg - December 16, 2025, 05:49:45 AMAm I doing something wrong with the install or the build. Do I have to donload and build some of the packages manually? Here is a record of my console during the install
https://docs.google.com/document/d/1JUA_x8jeGxl6YFJ1aabYQx-sGPzPqkZ5/edit?usp=sharing&ouid=115041733466386284875&rtpof=true&sd=true
https://docs.google.com/document/d/1JUA_x8jeGxl6YFJ1aabYQx-sGPzPqkZ5/edit?usp=sharing&ouid=115041733466386284875&rtpof=true&sd=true
#90
25.7, 25.10 Series / Re: Issue with Kea DHCP server
Last post by coatmaker618 - December 16, 2025, 05:21:42 AMA much belated update after much stress & chaos -- but a solution! You were correct Passeri, this is NOT a Kea related issue at all.
There were a few problems, but I believe the two big ones were:
1. VLAN #1 being treated differently by different systems. Some have it as a default, some have it as a normal VLAN. The equipment I started on treated it normal so I made the mistake of relying on it. Won't do that again!
2. It turns out that the MS-01 uses vPro -- an IPMI that uses a shared network port (unlike iDrac). Further, a subset of vPro (conveniently including the MS-01) does not turn off entirely even when you specifically tell it to turn off, and continues to have certain parts running which happen to include some sort of network management which interferes with certain packets (such as DHCP packets) before the OS has a chance to see them.
So the packets were being sent to the hardware just fine, but the OS never saw them. As soon as I swapped to ports outside of vPro's scope it all worked fine!
Hopefully others will find this information useful, it sure wasn't easy to find or diagnose (until I knew exactly what to look for).
There were a few problems, but I believe the two big ones were:
1. VLAN #1 being treated differently by different systems. Some have it as a default, some have it as a normal VLAN. The equipment I started on treated it normal so I made the mistake of relying on it. Won't do that again!
2. It turns out that the MS-01 uses vPro -- an IPMI that uses a shared network port (unlike iDrac). Further, a subset of vPro (conveniently including the MS-01) does not turn off entirely even when you specifically tell it to turn off, and continues to have certain parts running which happen to include some sort of network management which interferes with certain packets (such as DHCP packets) before the OS has a chance to see them.
So the packets were being sent to the hardware just fine, but the OS never saw them. As soon as I swapped to ports outside of vPro's scope it all worked fine!
Hopefully others will find this information useful, it sure wasn't easy to find or diagnose (until I knew exactly what to look for).
