Messages

Siehe oben, wenn du Hardware hast, bei der das relevant wird, hast du noch ganz andere Sorgen.

I read the release info but not really sure: WHEN does one have to press the migration button at the latest? Before 26.1.xyz? Before 26.7? Never?

Little confused...

is the old openvpn really gone then? so i cannot upgrade.

What exactly do you need that is not in the new OpenVPN?

Keys, maybe? ;-)

Tumbleweed is quite stable. Most of the time, you have to know, when you better NOT update, but that's not that hard.

The devices with Coreboot are "in production", so not easy to swap the OS. And as the problem is with TW updates, not with the browser (see above): how to test then?

So largely: Self-inflicted pain, one might say. It bugs me not to know, what is going on here. OPNsense has no traffic shaper enabled, what should IPS/IDS do to the bandwith of one client, but not to another on the same switch?

Weekly Tumbleweed updates and on starting the update download for a very short moment I see download with 5.6MiB/s, which immediately collapses to 300-400KiB/s and persists at creepy bandwidth.

What is going on here? FAST has 10.6MiB/s with same servers at same time.

PS: Just for the record: Confirmed again that both machines use identical, hard-coded update servers.

What can downgrade HTTPS for a specific client? Fingerprinting, ID of install, whatever?

Ladies and Gentlemen,

apparently we are running out of options here. Don't want to mess with the driver, as long as the machine is remote, just in case I loose network connectivity.

EEE, ASPM, offloading apparently not the culprit, what might be an option?

Then I see on SLOW:

20260121150015,127.0.0.1,48856,127.0.0.1,45678,1,0.0-30.0,117651669056,31373002456

Tells me what? ;-)

With EEE disabled in kernel I get:

Code Select Expand

sudo dmesg | grep EEE
[    0.000000] [      T0] Command line: BOOT_IMAGE=/boot/vmlinuz-6.18.5-1-default root=UUIDxxxxxxx splash=silent net.ifnames=0 kvm.enable_virt_at_load=0 ipv6.disable=1 quiet igb.EEE=0 mitigations=auto
[    0.018795] [      T0] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.18.5-1-default root=UUIDxxxxxxxx splash=silent net.ifnames=0 kvm.enable_virt_at_load=0 ipv6.disable=1 quiet igb.EEE=0 mitigations=auto

and still

20260121143745,FAST,SLOW,45678,1,0.0-30.1,1692139584,450325523

so no progress here.

With pcie_aspm.policy=performance in the kernel boot line I see:

Code Select Expand

sudo dmesg | grep ASPM
[sudo] password for root:
[    0.121549] [      T1] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]

and the troughput is:

20260121142126,SLOW,FAST,45678,1,0.0-30.0,3487694912,929146430

20260121142412,FAST,SLOW,45678,1,0.0-30.0,1691353152,450561206

...so no change here.

dmesg reports ASPM disabled. I edit the kernel boot line in YaST, that does the grub mkinit magic stuff automatically ;-)

I have here after reboot:

Code Select Expand

sudo dmesg | grep ASPM
[    0.018934] [      T0] PCIe ASPM is disabled
[    0.121764] [      T1] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]


Code Select Expand

iperf -p 45678 -c FAST -t 30 -y C -P 1
20260121133626,SLOW,FAST,45678,1,0.0-30.0,3478388800,926208295

Other direction:

20260121133925,FAST,SLOW,45678,1,0.0-30.1,1693319232,450764744
So nothing really changed.

OK, so best bet is:

Code Select Expand

pcie_aspm=off
added to kernel boot line and reboot.

Will try... :-)

@OPNenthu Thanks for reading, yes, ASPM and offloading are apparently off the list at that point.

EEE (enabled, but apparently "inactive", see above) and the "wrong" driver (8169, which works perfectly on another Tumbleweed with old ATOM CPU with legacy BIOS and Realtek 8168 hardware, btw...) are on the list.

Not much left, apparently...

RE 1: Checked the status for offloading:

Code Select Expand

sudo ethtool --show-offload eth0
[sudo] password for root:
Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off
        tx-tcp-accecn-segmentation: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
So GSO and TXO apparently off at the moment

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

Will try the suggestions and report back :-)