Recent posts

#51
26.7 Series / Re: Post 26.7.4 Wireless Issue
Last post by TrustedComputer - September 24, 2026, 01:46:27 AM
Thanks Franco. I think I had two things going on. The USB Wireless adapter hardware was going bad was the big one. After replacing with an identical tp-link AC600 Archer T2U Nano, I got things going again but it still doesn't like being turned off and on. Here's what I see from the console:

rtwn0: rtwn_tx_beacon_check: cannot push beacon into chip, error 60!
rtwn0: unable to push beacon into the chip, error 60
rtwn0: rtwn_newstate: could not move to RUN state
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_tx_beacon_check: cannot push beacon into chip, error 60!
rtwn0: unable to push beacon into the chip, error 60
rtwn0: rtwn_newstate: could not move to RUN state
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT


Like you said, I think the firmware must be buggy.
#52
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by dragao-azul - September 24, 2026, 12:03:16 AM
Thanks, here's the result of those:

root@OPNsense:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: kvmclock
root@OPNsense:~ # sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(-100) i8254(0) ACPI-fast(900) kvmclock(975) dummy(-1000000)
root@OPNsense:~ # sysctl kern.timecounter.fast_gettime
kern.timecounter.fast_gettime: 1
root@OPNsense:~ #
root@OPNsense:~ # sysctl kern.eventtimer.timer
kern.eventtimer.timer: LAPIC
root@OPNsense:~ # sysctl kern.eventtimer.choice
kern.eventtimer.choice: LAPIC(600) i8254(100) RTC(0)
root@OPNsense:~ # sysctl kern.eventtimer.periodic
kern.eventtimer.periodic: 0
root@OPNsense:~ #
root@OPNsense:~ # sysctl kern.eventtimer.et.LAPIC.frequency
kern.eventtimer.et.LAPIC.frequency: 500003658
root@OPNsense:~ # sysctl kern.eventtimer.et.LAPIC.quality
kern.eventtimer.et.LAPIC.quality: 600


No, they don't coincide with snapshots or backups of this or other VM/LXC in the system. I can't say they never match as I do have 15min snapshots  (zfs) and not very precise detection of this, but the distribution is random, I have plenty of examples falling out of the snapshot/backup timestamps. It's like 5 events per hour, sometime less sometimes more.


Timers do seem relevant though - I'm parroting ChatGPT a bit, but it helped me build some dtrace analysis and (I'll quote a paragraph):

...
More importantly, the fourth capture did work, and it contains exactly the evidence we were looking for. There are substantial samples in:
tcp_timer_rexmt
tcp_timer_enter
softclock_call_cc
softclock_thread

and also a large amount of networking processing around tcp_input_with_port, IPv6, netgraph, VirtIO, etc.

So the earlier clock observation was real: at least during this event, softclock_thread is spending time processing TCP retransmission timers. That is a significant narrowing of the problem.
...


EDIT: taking a hint from the linked post thread:

root@OPNsense:~ # vmstat -i | grep timer
cpu0:timer                       8789276        829
cpu1:timer                        312606         29
cpu2:timer                        316936         30
cpu3:timer                        281377         27
#53
Zenarmor (Sensei) / Re: Zenarmor on the DEC850
Last post by abenaou - September 23, 2026, 11:07:03 PM
If you plan to run Zenarmor in native netmap mode you have to widen the queues to avoid starvation and interfaces crashes down the road, look at my post where I implemented a solution that fixed my native netmap mode that caused incessant interfaces restarts, this fixed my igb interfaces issues and might work for igc providing the nic is compatible.
#54
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by meyergru - September 23, 2026, 10:17:33 PM
That was only a boot issue and does not explain these short outages. I would try disabling multiqueue on the NICs of the OPNsense VM.

There have also been reports of a current issue that may be related:
https://forum.opnsense.org/index.php?topic=52420.0

Can you give the output of:

sysctl kern.timecounter.hardware
sysctl kern.timecounter.choice
sysctl kern.timecounter.fast_gettime

sysctl kern.eventtimer.timer
sysctl kern.eventtimer.choice
sysctl kern.eventtimer.periodic

sysctl kern.eventtimer.et.LAPIC.frequency
sysctl kern.eventtimer.et.LAPIC.quality

Also, do the outages coincide with VM snapshots or backups?

#55
Q-Feeds (Threat intelligence) / Re: Q-Feeds, Suricata, Crowdse...
Last post by Q-Feeds - September 23, 2026, 10:12:32 PM
I won't comment on the other solutions, as I may be a little biased, but with Q-Feeds you're unlikely to notice any performance impact. You may even save resources by placing it upstream, since solutions that perform more intensive behavioral analysis won't need to process threats that Q-Feeds has already filtered out.
#56
General Discussion / Re: moving from PFsense to OPN...
Last post by pfry - September 23, 2026, 10:10:42 PM
Quote from: trident on September 23, 2026, 07:44:46 PMhi am trying to moving from PFSense to OPnSence[...]

If you have the pfSense installation handy you could grab its raw rule configuration and compare it to what you have on OPNsense. I don't know if it's available in the GUI in pfSense; it is in OPNsense. Or there are various standard pf methods (probably the config files would be easiest).
#57
General Discussion / Re: moving from PFsense to OPN...
Last post by Patrick M. Hausen - September 23, 2026, 10:00:05 PM
The default HTTP --> HTTPS redirect rule will catch traffic on all interfaces. Best disable it, you don't want the UI over plaintext HTTP, anyway.
#58
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by dragao-azul - September 23, 2026, 09:40:23 PM
Unfortunately I need to go back on my words: while everything was good for 1 day the problem came back again.

The only thing I did to make it better were a few restarts of the opnsense VM and removing the passthrough from the VM.


I've tried another reboot (of opnsense), but even immediately after that the issue repeated itself.


I noticed a post above about PPP(oE) and my WAN is a PPPoE connection (no VLAN) in case that makes a difference, but I get the feeling the post might be some unrelated boot issue?

I'll try to dig a bit further, but any pointer on the best way to go about identifying the problematic process/thread/interrupt sources would be helpful.

Thanks!
#59
General Discussion / Re: moving from PFsense to OPN...
Last post by trident - September 23, 2026, 09:32:28 PM
port 80 wan go to a web not the gui with no problem as webgui should never be on wan only on lan
#60
Hardware and Performance / Re: Upgrade from J6413 Questio...
Last post by nero355 - September 23, 2026, 09:20:32 PM
Quote from: meyergru on September 23, 2026, 06:05:00 PMAlas, the "cheap" hardware options have left the building a while ago :-(
100% AGREE :'(