Messages

[beep]

..I'm not sure what hardware brand or version of OPNSense you're running, but this also happened to me. I was just tinkering with it today. I have a Lenovo M720q Tiny as well as a M715q Tiny. The beep can be heard on the M715q but not on the M720q..

I'm running a Lenovo® M90n-1 Nano and encountered the same problem: No friendly OPNsense beeps on startup/shutdown. Definitely mission-critical, couldn't let it go unaddressed.

After some poking around I got it fixed. There were three separate problems:

• Two different versions of the "beep" binary, one of which doesn't work on my system.
• The opnsense-beep shell script calling the wrong (non-functional) version of "beep."
• The opnsense start / stop beep sound definition files contain beep durations in bare integers that are interpreted as "centiseconds" by one version of beep, but as "milliseconds" in another version of beep.

There are for whatever reason multiple versions of the "beep" binary on my system. (25.7.8.) (As best I can tell it looks like one might use /dev/speaker and another version uses /dev/dsp instead? )

Each of these versions has different command-line options, and only one of them (/usr/bin/beep) actually makes sounds on my system.

Code Select Expand

root@router:~ # ls -al /usr/bin/beep
-rwsr-xr-x  1 root wheel 10088 Nov 24 23:26 /usr/bin/beep
# This version interprets tone-length integers as millisecond values, and it
# works (makes beep noises) on my system.

root@router:~ # ls -al /usr/local/bin/beep
-r-xr-xr-x  1 root wheel 7584 Jul 21 16:21 /usr/local/bin/beep
# This version interpretes tone-length integers as centi-second values, and it
# DOESN'T work (no sounds) on my system.

The /usr/local/sbin/opnsense-beep script, as-shipped, calls /usr/local/bin/beep.

So I altered the script it to call the other version of beep instead. I also altering the command-line flags as-required.

Code Select Expand

root@router:/usr/local/sbin # diff opnsense-beep opnsense-beep-ORIGINAL
69c69
<      /usr/bin/beep  -F "${NOTE}" -D "${DURATION}" -g 100
---
>         /usr/local/bin/beep -p "${NOTE}" "${DURATION}"

#  The -g 100 argument optionally boosts the output volume to 100%, which is necessary
#  for the tiny speaker in this system.

But after doing this, while I could type, say, /usr/bin/beep -F 1000 -D 100 from the command line and it would work fine, the opnsense-beep script still wasn't working.

I finally checked the beep-sound definition files in /usr/local/etc/opensense-beep.d/* and found them to have DURATION lengths of "25." Those lengths were meant for the (non-working, on my system)
/usr/local/bin/beep, which takes tone lengths in units of centi-seconds. (Hundredths of a second.)


But /usr/bin/beep  takes tone lengths in units of milliseconds, with 50 ms the lowest-valid value.  Once I changed the beep definitions in the /usr/local/etc/opensense-beep.d/* tune definition files from "25" to "250," my modified version of /usr/local/sbin/opnsense-beep started producing the usual friendly beep sounds.


FWIW, here are the audio devices as-reported on my system:

Code Select Expand

root@router:~ # cat /dev/sndstat
Installed devices:
pcm0: <Realtek ALC235 (Analog 2.0+HP/2.0)> (play/rec) default
pcm1: <Intel Kaby Lake (HDMI/DP 8ch)> (play)
No devices installed from userspace.

Just chipping in my 2 bits --

While there are a lot of places where Opnsense's web UI could be improved or re-worked, IMO ALL of that sort of intention to polish and optimize the UI/UX -- 100% of it, every last bit -- is secondary, possibly even tertiary, to the reasons I use Opnsense in the first place:

• Stability
• Broad feature set with fine-grained configurability
• Frequent security updates.

Just continuing to keep the above 3 priorities fully-realized, as I believe they are now, is enough to keep me satisfied going forward.

Granted, ones's use case does influence such an opinion. That is to say as a small-time user who runs 3 small separate site networks on Opnsense, I probably only touch firewall rules, VLAN & interface assignments, etc. a few times a year, and when I do, all I care about is that they continue to work as-expected and reliably, regardless of whether it takes me 8 clicks or 58 clicks to make a change.

If I was a network admin in a enterprise setting, configuring one more new Opnsense instances a week, I might have a stronger wish for UI/UX polishing.

(*cough* that said, it sure would be nice to be able to copy-and-paste firewall rules between interfaces, say, by ticking the rule-selector checkbox and clicking "copy to Interface X"...  although, thinking that through further, it might grease the rails overmuch towards people making broadly insecure and/or breaking changes to their firewall rule sets.)

What is the approximate timeline for when ISC DHCP is going to be removed from OPNsense?


1 quarter?  1 year?  5 years?

I tried to follow this whole thread but found it a bit confusing.


For anyone who happens to be running PCengines APU2-series boards, all 3 of my APU2-based opnsense boxes, running ZFS,  applied the 24.7.2 update without any problems.  No kernel panics or other weirdness.

Update process was smooth on (3) different bare-metal PCengines APU2-series boxes.  Two APU2E4s and 1 APU2C4. (4GB RAM in each device.) All upgrading from 24.1.10.

Interestingly, upgrade time varied from as short as 5 minutes to as long as 16 minutes.

All settings appear to have been preserved. Multiple site-to-site wireguard VPN tunnels came back up without any tweaking.

I'm not sure what I think of the new dashboard yet. Widgets all seem broken but I'm sure this will get worked out eventually. Dashboard + widgets are cosmetic, not required.

Why did you go with 23.x and not 24.x?

... Because 23.x was what was current as of the date of that post, circa July 2023...


I don't use Suricata, Crowdsec, or Suricata..

If I had to publish a read-only status page for a router or other security-senstive device on a LAN, I would not expose any part of the actual device's web interface to end users.

I'd write a script running on a bastion host or similarly-purposed separate device to collect the router's status info using curl or perhaps even an API call to the router, & then reformat & republish the collected info on a separate web server. (Not hosted on the router itself.)

To the best of my knowledge, all Wireguard settings, tunnels, keys, etc. are preserved in the main config.xml file which is the "master configuration" for an OPNsense instance. No special or separate backup of WG settings should be required in a normal backup / restore scenario.

Interesting. I tried adding all those tunables (via the GUI) to my OPNsense instance, then re-testing using the physical 1Gb ethernet setup I described earlier and same iperf3 options. No discernable difference at all, still tops out at about 600 Mbps.

Before you do much else I would contact the ISP, 2nd tier tech support or higher, and confirm their policy on customer-provided equipment. If they're blocking you, not a lot of sense tearing your hair out to try to figure out what's wrong on your side.

Sorry for the excess posts, I just noticed also that OP is running a PPPoE WAN connection.

Multiple articles & forum threads on APU2-series over the past several years indicates that PPPoE WAN tends to severely limit throughput because, as I understand it, by nature PPPoE only allows a single network connection at a time.

In my single TCP connection testing with APU2, the max throughput I saw under best-case LAN conditions was just 137 Mbit / second. The only way I could achieve 600Mbit per second described in earlier posts was by running multiple connections at once.

I will add further --

Several years ago, circa ~2018 to 2020 or so, there were posts and articles floating around demonstrating how to achieve true 1Gbps (actually ~950Mb/sec) throughput with an APU2-series device + pfSense (and possibly OPNsense), but this was under earlier versions of FreeBSD.

From what I gather, core aspects of the network stack have been changed in some ways in more recent versions of FreeBSD that "break" those older optimizations, perhaps making it no longer possible to achieve that ~1Gbps throughput.

If that is the case, probably at least part of what is going on is that the APU2-series boxes use a CPU that is now fully 1 decade old, and there is no longer much interest in trying to squeeze performance out of it.

Probably if one wants to route 1Gbps-and-more under recent or current versions of OPNsense, the simpler approach would be to upgrade to much more recent hardware with more basic CPU power. (And good Intel™ NICs, not Realtek or other derivatives.)

In my case, my WAN ISP connection is only ~95 Mbps and I have no need for anything beyond 500 Mbps on the LAN side, so I'll continue to use my trusty APU2E4 for the time being.

A lot of reading I've done of many older threads on this topic seems to suggest that with OPNsense running on a PCEngines APU2E4 the max achievable throughput on a single NIC may be ~600 Mbit second under ideal conditions.

I have an APU2E4  (which has the Intel 210AT NICs, i.e. "the good ones,") and have been doing some iPerf3 testing recently to see "where things are" with max theoretical performance.

In the following hardware setup:

MacBook Pro 16" M1 laptop --> Belkin 1GB USB-Ethernet converter --> new 7' long "Cable Matters™" Cat6e patch cable --> APU2E4 igb2 port, configured as a simple no-vlan static IP subnet.

And this OPNsense version:

root@myhost# uname-a
FreeBSD myhost.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64

And the following iPerf3 settings:
server (running on the APU2E4 Opnsense box):

Code Select Expand

iperf3 -s

client (running on the MacBook Pro 16" M1Pro):

Code Select Expand

iperf3 -c 192.168.7.1 -w 1MB  -P 8

the results look like this:

Code Select Expand

[SUM]   0.00-10.00  sec   724 MBytes   607 Mbits/sec                  sender
[SUM]   0.00-10.01  sec   710 MBytes   595 Mbits/sec                  receiver


So far, no settings of any kind within OPNsense GUI (Interface --> Settings, or System --> Settings --> Tunables) seem to make any impact at all. Neither does enabling / disabling the firewall, or enabling/disabling the 2 small /low bandwidth Wireguard tunnels I have configured.

Granted, it may be that this limit is due to trying to run iperf3 (in server mode) ON the OPNsense box itself. At present I only have 1 laptop to test with, no other devices. Perhaps if I get a second laptop + ethernet adaptor and try the iperf3 test between the two laptops, routed through the OPNsense box, I will see higher bandwidth because OPNsense / BSD kernel is not busy trying to run iperf itself during the test.

I know the parent doesn't need to be assigned, but then it's just sitting there in the little drop down where it could be assigned by accident.  That's why I assigned it a disabled interface.

I noticed this. When set up my VLANs I assigned a primary interface for each because I thought it was required.


Now I see there's no way to unassign them through the GUI. Is this an oversight in GUI design that could/should be fixed?

Replying further, as I found another relevant thread on this turbostat core-dump issue:

https://forum.opnsense.org/index.php?topic=30148.msg145554#msg145554

In my case, I think I did install the most-recent version of turbostat, but it's still crashing. Oh well, I guess no resolution at this time:

Code Select Expand

root@myopnsenserouter:~ #  file /usr/local/sbin/turbostat
/usr/local/sbin/turbostat: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2, FreeBSD-style, stripped

root@myopnsenserouter:~ # uname -a
FreeBSD myopnsenserouter.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64