Recent posts

#91

25.7, 25.10 Series / Re: New site PPPoE PMTU woes

Last post by meyergru - Today at 09:06:16 AM

Not quite. Obviously, you can currently use an MTU of 1492 bytes only according to your tests. That I read from your previous posts and it hold true unless you succeed in applying the method explained here to enlarge that WAN MTU to 1500 bytes. In order to do that on a Proxmox VM, the whole chain ISP -> physical NIC -> Proxmox bridge -> OS NIC -> OS VLAN -> OS PPPoE WAN Interface must be configured right and capable to support 1500 bytes MTU on the WAN interface.

Without that, at least on the WAN side, you obviously need a 1492 bytes MTU, probably because of PPPoE involved in your WAN setup.

From there, you have two options:

1. Use a LAN MTU of 1500 bytes and employ MSS clamping (Firewall: Settings: Normalization) to adapt the mismatch of WAN vs. LAN MTU.
2. (Better) Use a LAN MTU of 1492 bytes, too.

#92

General Discussion / Re: Where is TCP processed - C...

Last post by chemlud - Today at 08:33:23 AM

@klevinsourd, that was my impression, explaining the thread title ;-)

Will try the suggestions and report back :-)

#93

General Discussion / Re: Where is TCP processed - C...

Last post by klevinsourd - Today at 08:18:57 AM

Hi, have a problem that bugs me for years, no solution found yet:

Two clients with Linux, same update status:

1. SLOW: Libretrend i7 with Coreboot, Realtek NIC

2. FAST: Old Dell Precision M6500 notebook with Intel NIC.

Problem: when downloading e.g. updates, the FAST ist 30-times faster than SLOW, see attached.

Same mirrors,RJ45 cables changed twice, both attached to the same switch. So no real explanation.

Yesterday I did some iperf between the two clients.

For UDP, it does not matter, which is server and whicch is client:

20260118145326,SLOW,FAST,45678,1,0.0-30.0,3935190,1048952,0.025,0,2677,0.000,0

20260118145446,FAST,SLOW,45678,1,0.0-30.0,3935190,1048950,-nan,0,-1,-0.000,0

But for TCP direction matters:

20260118144505,SLOW,FAST,45678,1,0.0-30.0,3533963328,941434163

20260118144740,FAST,SLOW,45678,1,0.0-30.1,1690173504,449722645

-------------------------

First thought: RJ45 in SLOW machine is Realtek. But I have Realtek in other machines with same linux, always maxing out the bandwith possible. So I don't think it'S simply Realtek.

Why only TCP makes a difference? Is there offloading and that doesn't work properly in the SLOW machine? Maybe due to Coreboot @soundboard?

Any ideas how this difference in TCP-speed might be explainable?

:-)

Based on your iperf results and the specific hardware combination (Realtek + Coreboot), this is a classic case of TCP Offloading or Interrupt Throttling issues common with Realtek drivers on Linux.
Here is an analysis and potential solutions:
1. The "TCP vs. UDP" Clue: Hardware Offloading
The fact that UDP works fine but TCP is slow strongly points to TCP Segmentation Offload (TSO) or Generic Segmentation Offload (GSO). Realtek chips often have buggy implementations of these features in their firmware/drivers.
When these are enabled, the NIC tries to process TCP packets itself to save CPU. If it fails, it leads to packet retransmissions and massive slowdowns.
The Fix: Disable offloading on the SLOW machine:
bash
sudo ethtool -K <interface_name> tso off gso off gro off
Use code with caution.

Try running your iperf test again after this.
2. Driver Conflict: r8169 (Kernel) vs. r8168 (Vendor)
Most Linux distros use the open-source r8169 driver by default. While improved, it still struggles with certain Realtek revisions, especially regarding Receive Side Scaling (RSS).
The Fix: Install the official Realtek driver (often found as r8168-dkms in your package manager):
Ubuntu/Debian: sudo apt install r8168-dkms
Arch: sudo pacman -S r8168
Note: You may need to blacklist the r8169 driver in /etc/modprobe.d/.
3. Coreboot & ASPM (Power Management)
Coreboot sometimes doesn't initialize PCIe Active State Power Management (ASPM) correctly. If the Realtek chip enters a low-power state (L1) during the tiny gaps between TCP acknowledgments, the latency spikes and throughput collapses.
The Fix: Disable ASPM via the kernel command line:
Edit /etc/default/grub.
Add pcie_aspm=off to GRUB_CMDLINE_LINUX_DEFAULT.
Update grub (sudo update-grub) and reboot.
4. Energy Efficient Ethernet (EEE)
Realtek NICS often have "Green Ethernet" (EEE) enabled. This can cause synchronization issues with certain switches, leading to the 30x speed difference you see.
The Fix: Disable EEE:
bash
sudo ethtool --set-eee <interface_name> eee off
Use code with caution.

Why the Dell (Intel NIC) is faster:
Intel NICs (like the one in your M6500) have superior hardware-level buffers and much more mature Linux drivers. They handle TCP window scaling and offloading far more gracefully than Realtek chips, which rely heavily on driver-side workarounds.
Recommended sequence for troubleshooting:
Test 1: Disable TSO/GSO with ethtool (Immediate effect, no reboot).
Test 2: Disable EEE.
Test 3: Switch from r8169 to r8168 driver.
Test 4: Disable pcie_aspm in GRUB.

hope can help you

#94

25.7, 25.10 Series / Re: Dnsmasq logging configurat...

Last post by Monviech (Cedrik) - Today at 08:11:17 AM

https://github.com/opnsense/core/pull/9632

#95

25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...

Last post by LHoust - Today at 06:26:53 AM

I was also observing hostwatch running at nearly 100% CPU...

I Proof my OPNsense Updates within a VirtualBox VM running on an Ubuntu 24.04.3 Host, where my /home Partition sits on a HDD...

With 25.7.11_2 I was also observing a Serious Level of HDD Thrashing, until I disabled Automatic Discovery!!!

For Proofing Updates, I also run OPNsense 25.7 within a Workstation VMPlayer VM: Host is Windows 11 (C: Drive is a SSD)...

Everthing seems "Quite" HERE??

#96

25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...

Last post by passeri - Today at 05:25:27 AM

Just to mention, on one test box and two operational boxes, all bare metal Intel and AMD, hostwatch trots along quietly with no untoward CPU spikes or log writes. Three principal subnets (no vlans), all IPv4, around 25 devices.

#97

25.7, 25.10 Series / Dnsmasq logging configuration ...

Last post by Deckard - Today at 04:53:36 AM

Hi, I don't know if this has been reported before.  I recently switched from ISC to dnsmasq and today noticed a plethora of log overflow errors, so I attempted to adjust the logging level.

Code Select Expand

2026-01-20T15:37:42-08:00 Warning dnsmasq overflow: 15 log entries lost
2026-01-20T15:37:42-08:00 Warning dnsmasq overflow: 4 log entries lost
2026-01-20T15:37:42-08:00 Warning dnsmasq overflow: 15 log entries lost
2026-01-20T15:09:39-08:00 Warning dnsmasq overflow: 9 log entries lost

I had enabled "Log DHCP options and tags" and was seeing those when viewing informational logs, so I disabled the option and saved settings.  However, the logging did not change.

It appears that no matter what log settings are selected in the configuration, the logging options in the dnsmasq.conf file do not change.  Other settings such as 'no-hosts' apply correctl.

/conf/config.xml fragment:

Code Select Expand

    <dhcp>
      <no_interface/>
      <fqdn>1</fqdn>
      <domain/>
      <local>1</local>
      <lease_max/>
      <authoritative>1</authoritative>
      <default_fw_rules>1</default_fw_rules>
      <reply_delay/>
      <enable_ra>1</enable_ra>
      <nosync>0</nosync>
      <log_dhcp>0</log_dhcp>
      <log_quiet>0</log_quiet>
    </dhcp>

Code fragment from the template /usr/local/opnsense/service/templates/OPNsense/Dnsmasq/dnsmasq.conf:

Code Select Expand

{% if dnsmasq.dhcp.log_dhcp %}
log-dhcp
{% endif %}
{% if dnsmasq.dhcp.log_quiet %}
quiet-dhcp
quiet-dhcp6
quiet-ra
quiet-tftp
{% endif %}
Template output from /usr/local/etc/dnsmasq.conf:

Code Select Expand

log-dhcp
quiet-dhcp
quiet-dhcp6
quiet-ra
quiet-tftp


#98

25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...

Last post by LHoust - Today at 04:37:25 AM

I was also observing hostwatch running at nearly 100% CPU...

I Proof my OPNsense Updates within a VirtualBox VM running on an Ubuntu 24.04.3 Host, where my /home Partition sits on a HDD...

With 25.7.11_2 I was also observing a Serious Level of HDD Thrashing, until I disabled Automatic Discovery!!!

#99

25.7, 25.10 Series / Re: Dnsmasq stops occasionaly

Last post by ligand - Today at 03:33:32 AM

Message sent to the list.  Will keep everyone posted.

#100

25.7, 25.10 Series / Re: New site PPPoE PMTU woes

Last post by ToasterPC - Today at 03:04:02 AM

In theory, MSS should be set to MTU-40, but OpnSense does some trickery with the input value, so I would not set it at all.

Set it to the MTU and OPNsense will use MTU - 40 for IPv4 and MTU - 60 for IPv6 which is the reason why you do not put the effective MSS in that field. Because that is different for both protocols.

Okay, so from what I'm gathering, only the MTU should be set in OPNsense itself, and both the Proxmox VirtIO interfaces and their bridges (in WAN and LAN) should stay at the default 1500 MTU value in order to have OPNsense make the corresponding calculations for each protocol.

Do I have the right of it?