"Recent posts
#1
26.1, 26,4 Series / Re: Unstable internet connecti...
Last post by GCustom - Today at 09:10:05 AMQuote from: pseudonym3k on February 17, 2026, 05:43:21 PMQuote from: demyers on February 09, 2026, 05:23:36 PMThis might not be your problem, but I've found that some providers, particularly wireless providers, sometimes drop the abnormally small ping packets sent by dpinger. For all of my gateways I set "Data Length" to 56 (you'll need to switch on "Advanced Mode" to see this option).Just came in here again to say changing the data length to 56 has solved the issue for me (as far as dpinger giving false positives). I have been externally monitoring my own IP as well as the IP I am using for the monitor. The few failures I get now are due to monitor IP unreachable but my own connection was working.
I still need to think on monitoring as a whole in my situation. It is useful to me to know when my connection was disrupted, but only if actually true. If dpinger could check several IPs in series, and only if all fail assume the gateway unusable, it would mitigate the false positives from a single monitor IP being unreachable.
This one has been biting me several times over the past few weeks with my combination of ISPs and monitor addresses. I have multiple ISPs, and gateway flapping while I'm on a livestream is brutal.
Changing Data Length from the default 1 to 56 has already made a dramatic difference for me, so thanks for that. But I think the larger problem is still relying on a single monitor IP as the authority for whether a gateway is usable.
I'd really like to see multiple monitor targets per gateway, with some simple quorum/weighting logic, e.g. if one target stops answering but two others are healthy, don't declare the connection down. Those same few well-known targets could be reused across gateways while each gateway probes them through its own connection.
Recovery could use some asymmetry too: fail me off reasonably fast, bring me back more slowly. I'd rather require sustained evidence that a recovered connection is healthy before putting new states back on it than flap back and forth during an intermittent problem.
In short: one unreachable IP shouldn't be enough to declare an entire Internet connection dead, and recovery doesn't necessarily need to be as eager as failure detection.
#2
26.7 Series / Re: Why is he doing this? grap...
Last post by Patrick M. Hausen - Today at 09:03:11 AMYou have multiple apparently conflicting repositories.
#3
26.7 Series / Why is he doing this? graphite...
Last post by halasizs - Today at 08:35:07 AMWhy is he doing this? Do you always erase and install the same thing back? I've noticed him before.
You cannot view this attachment.
You cannot view this attachment.
#4
General Discussion / Re: http_proxy for bogons-upda...
Last post by OPNjk - Today at 08:33:54 AMI recently added a "URL Table (IPs)" alias to the configuration of this firewall cluster.
What I realized: when I configure the table's URL in the GUI the request is being sent via the configured proxy. The hourly refetch of the URL is not done via the proxy at all: the proxy log is empty and I verified in a packet capture that the firewall retrieves the file directly. The log on the standby firewall (that does not have Internet access in the setup) has following log entry that also points in that direction:
I had a quick look into iter_addresses source code (alias/uri.py) and it looks as though no proxy is being set there?
What I realized: when I configure the table's URL in the GUI the request is being sent via the configured proxy. The hourly refetch of the URL is not done via the proxy at all: the proxy log is empty and I verified in a packet capture that the firewall retrieves the file directly. The log on the standby firewall (that does not have Internet access in the setup) has following log entry that also points in that direction:
Code Select
(Caused by NewConnectionError("HTTPSConnection(host='<hostname>', port=443): Failed to establish a new connection: [Errno 65] No route to host")))
I had a quick look into iter_addresses source code (alias/uri.py) and it looks as though no proxy is being set there?
#5
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by meyergru - Today at 08:14:13 AMThanks. This does not look like the LAPIC calibration problem from the thread I linked.
Your LAPIC frequency of about 500 MHz looks sane and is almost exactly what was reported for the working Proxmox case there. The broken case had a frequency off by roughly three orders of magnitude and around 65k timer interrupts/sec on every vCPU.
The `vmstat -i` numbers are interesting, but note that the displayed rate is averaged since boot, so it may hide what happens during one of the short stalls.
Since you are using `kvmclock`, I think one simple A/B test would still be worthwhile:
Leave everything else unchanged and see whether the stalls still occur. With several events per hour it should not take too long to get a useful result.
You can switch back with:
I would not conclude from the DTrace samples yet that the TCP retransmission timers are the cause. They may also be a consequence of the actual stall: if packet processing stops briefly, retransmission timers expire and `softclock_thread` subsequently has a lot of work to do.
The snapshot-related KVM clock problem I mentioned earlier also looks less likely in your case, since you have many events which clearly do not coincide with snapshots or backups.
Your LAPIC frequency of about 500 MHz looks sane and is almost exactly what was reported for the working Proxmox case there. The broken case had a frequency off by roughly three orders of magnitude and around 65k timer interrupts/sec on every vCPU.
The `vmstat -i` numbers are interesting, but note that the displayed rate is averaged since boot, so it may hide what happens during one of the short stalls.
Since you are using `kvmclock`, I think one simple A/B test would still be worthwhile:
Code Select
sysctl kern.timecounter.hardware=ACPI-fast
Leave everything else unchanged and see whether the stalls still occur. With several events per hour it should not take too long to get a useful result.
You can switch back with:
Code Select
sysctl kern.timecounter.hardware=kvmclock
I would not conclude from the DTrace samples yet that the TCP retransmission timers are the cause. They may also be a consequence of the actual stall: if packet processing stops briefly, retransmission timers expire and `softclock_thread` subsequently has a lot of work to do.
The snapshot-related KVM clock problem I mentioned earlier also looks less likely in your case, since you have many events which clearly do not coincide with snapshots or backups.
#6
26.7 Series / Re: Post 26.7.4 Wireless Issue
Last post by TrustedComputer - Today at 01:46:27 AMThanks 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.
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.
#7
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by dragao-azul - Today at 12:03:16 AMThanks, here's the result of those:
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:
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 linkedpost thread:
Code Select
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:
Code Select
tcp_timer_rexmt
tcp_timer_enter
softclock_call_cc
softclock_threadand 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
Code Select
root@OPNsense:~ # vmstat -i | grep timer
cpu0:timer 8789276 829
cpu1:timer 312606 29
cpu2:timer 316936 30
cpu3:timer 281377 27
#8
Zenarmor (Sensei) / Re: Zenarmor on the DEC850
Last post by abenaou - September 23, 2026, 11:07:03 PMIf 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.
#9
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by meyergru - September 23, 2026, 10:17:33 PMThat 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:
Also, do the outages coincide with VM snapshots or backups?
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:
Code Select
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?
#10
Q-Feeds (Threat intelligence) / Re: Q-Feeds, Suricata, Crowdse...
Last post by Q-Feeds - September 23, 2026, 10:12:32 PMI 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.
