pfSense

Christopher Cope wrote in #note-1:

That option is to enable an audible beep, such as through a PC speaker, for those notifications. Is that not working or were you expecting it to disable the notifications altogether?

(While I would prefer to not get the console/ssh session broadcasts at all) my complaint is that the "console bell" option has no effect; no matter which way I set it, an ascii 7 (bell) character is included in the broadcast message sent to the console and all ssh sessions:

^GMessage from syslogd@??? at Jul  4 12:41:52 ...^M
php-fpm[36962]: /index.php: User logged out for user 'admin' from: ??? (Local Database)^M

Craig Leres wrote in #note-2:

Christopher Cope wrote in #note-1:

That option is to enable an audible beep, such as through a PC speaker, for those notifications. Is that not working or were you expecting it to disable the notifications altogether?

(While I would prefer to not get the console/ssh session broadcasts at all) my complaint is that the "console bell" option has no effect; no matter which way I set it, an ascii 7 (bell) character is included in the broadcast message sent to the console and all ssh sessions:
[...]

The option toggles kern.vt.enable_bell.

This can be confirmed with the following command:

sysctl kern.vt.enable_bell

Ok, so kern.vt.enable_bell is not being obeyed:

pylon 79 # sysctl kern.vt.enable_bell
kern.vt.enable_bell: 0

with the above setting, I'm still getting an audible bell on the console and in ssh sessions.

To help find the root cause, here are the details of the tests I performed:

I started by installing a fresh copy of 26.03.1

Set kern.vt.enable_bell manually to 1, ran printf '\a', and confirmed a beep was output
Set kern.vt_enable_bell manually to 0, ran printf '\a', and confirmed no beep was output

I then went in to the GUI settings and changed the "enable console bell" option, confirmed the sysctl variable was updated, and did the printf tests again.

Finally, I left the console open while logging in with the GUI option disabled and enabled to confirm the behavior matched expectations.

I think it matters how you are connected to the pfsense box? In my case, if I ssh into pfsense from a FreeBSD system with kern.vt.enable_bell=1, it does not matter what kern.vt.enable_bell is set to on the pfsense box; when a bell is sent to a ssh session or the serial console it will make noise.

How are you connecting to pfsense such that you can make an emitted bell silent? Perhaps you are not using a netgate box at all? (I have a SG2100)

Craig Leres wrote in #note-8:

I think it matters how you are connected to the pfsense box? In my case, if I ssh into pfsense from a FreeBSD system with kern.vt.enable_bell=1, it does not matter what kern.vt.enable_bell is set to on the pfsense box; when a bell is sent to a ssh session or the serial console it will make noise.

How are you connecting to pfsense such that you can make an emitted bell silent? Perhaps you are not using a netgate box at all? (I have a SG2100)

To confirm, are you getting the bell on the FreeBSD system you are connecting from?

The character would still be passed through, so may be triggering it on your local machine. The sysctl option should disable the bell output on the physical device itself.

If you disable kern.vt.enable_bell on the FreeBSD system you are connecting from do you still get the bell?

Jim Pingle wrote in #note-10:

That option only influences the console bell on systems with a PC speaker.

It took awhile for us to get there but that's what I eventually figured out; it's a Fisher-Price checkbox when using a netgate appliance.

The behavior you are intending to control is influenced by the log level of certain messages. Certain "Emergency" messages can produce a terminal bell that is handled however your terminal program is configured to do so (could be visual, could be audible, etc). Some of those messages, from logins, can be controlled via the GUI login messages option under System > Advanced, Admin Access tab.

That's prefect, thank you!