Messages

The t5nex is a thermal sensor on a Chelsio T520-BT ethernet NIC. I believe the temperature for this device is being reported in Fahrenheit based on a quick search (widget is reporting it as "C").

Well, I would not be so sure. (Use your finger or - safer - IR thermometer.) They do run HOT. Around 70C definitely not unusual. 79F ~= 26C: very unlikely.

IR thermometer confirmed the heatsink temperature in the 79C range which is well beyond the specified operating range maximum of 55C for the card. I replaced the card with an identical T520-BT that I had in spares, and it is running at 53C.

Thanks for the input on this and the creation of the temperature widget which has allowed me to identify an apparently failing card that I had no reason to suspect. The Chelsio cards are 5+ years old so I will retire both of them.

Thanks for the pointer to the script. Executing the script returned the following for CPU 50 and Zone 0.

dev.t5nex.0.temperature=79
hw.acpi.thermal.tz0.temperature=27.9C

The t5nex is a thermal sensor on a Chelsio T520-BT ethernet NIC. I believe the temperature for this device is being reported in Fahrenheit based on a quick search (widget is reporting it as "C").

Thermal sensors widget display for an i7-13700K processor displays the 24 CPUs and it also displays a "CPU 50" and a "Zone 0". Does anyone know what "CPU 50" and "Zone 0" are reporting on?

Franco, thank you for your input. I tried two more reboots. The first worked, and the second one hung. The two changes I have made since upgrading to 24.7 is to migrate DHCP to KEA DHCP and to add NUT to SNMP query a UPS unit. KEA DHCP is working as expected, and the NUT diagnostics page is displaying the information for the UPS unit it is querying so. I will have to investigate further to see if one of those changes is responsible for the reboot failure.

I upgraded to 24.7.1 from 24.7_9. After the reboot I could not access the firewall via either web access or ssh. DNS requests to the firewall were reporting timeouts. The firewall may have been allowing some traffic through, but I did not investigate. I was able to do a console login and reboot. The firewall came up after the second reboot and is functioning normally.

My upgrade to 21.1 was successful, but it took a long time. The delay seemed to be with the download process. The steps I went through via web interface are:

- Upgraded to 20.7.8_4 which took about 3 minutes.
- Attempted upgrade to 21.1. It failed after 30+ minutes on the first package download with a checksum error.
- Rebooted firewall
- Started upgrade again. The first package download took about 90 minutes. The next two downloads took a couple of minutes. The firewall then rebooted and was fully operational in less than 5 minutes.

Most OPNSense upgrades take me less than 5 minutes. Opnsense is running on an SSD drive and has sufficient  CPU (quad core I7-3820) to sustain 1.2 gigabit downloads (Xfinity Gigabit service provisioned at 1.2 gigabit).

Just wanted to confirm that for some patience may be needed for this upgrade.

As one of the users who was seeing wan performance degradations with 20.7 I have resolved those problems. The primary problem every minute or a change of promiscuous mode for the Ethernet NICs was resolved by a clean install of 20.7.  My second performance issue turned out to be due to SFP+ module (transceiver) that was degrading performance. With those problems resolved I am able to sustain download speeds through OPNSense of 1.2 Gbit (Gigabit cable service provisioned at 1.2 Gb). I do not have IDS/IPS configured at this time.

An update to my original post.  With 20.7 I have only been able to restore download performance (940 Mb on a Gigabit service).  My upload performance remains very degraded.  My upload on OPNSense 20.1 was typically 42 Mb using Xfinity (ISP cable service) speed test and Dslreports speed test.  With 20.7 I get 3 to 4 Mb with the Xfinity speed test and 15 to 18 Mb with Dslreports speed test.  I also verified that Xfinity is still delivering the provisioned speeds by using a laptop connected to the cable modem in place of OPNSense and running the speed tests.  OPNSense processor utilization is in the 10% to 20% range when the speed tests are running.

I am also seeing some issues with IPv6 that I did not see on 20.1.  I disabled IPv6 to see if that would help performance.  My results were the same with IPv6 disabled.

With the upgrade to 20.7 I encountered a performance degradation that varied from moderate to severe.  Reviewing the logs I found the following messages were repeating every few seconds.

kernel: pflog0: promiscuous mode enabled
kernel: pflog0: promiscuous mode disabled

Rebooting did not solve the problem.  I did a reinstall of 20.7, recreated the interfaces and portions of the configuration, and restored parts of the configuration.  This resolved the frequent promiscuous mode changes, and resolved the performance issues.

I have disabled circular logging on 20.7 and I am seeing the once a minute syslog-ng destination timeout messages.  Services shows an error for syslogd.  I assume that syslogd not running is expected behavior.  I haven't looked to see what needs to be done to remove it from services monitoring.