Myslíš tyhle timeouty?
$ sysctl -a -r nf_flowtable
net.netfilter.nf_flowtable_tcp_timeout = 30
net.netfilter.nf_flowtable_udp_timeout = 30
Ano, myslím tyhle timeouty.
Pokud to je ono, tak je to už dávno fixnutý...
Vzhledem k tomu, že to pozoruji na kernelu 6.5.3, tak se mi to moc fixnutý nezdá.
Nemáš k tomu nějaký info? Odkaz na nějaký bugtracker, kde by byly podrobnosti?
Mám k tomu vlastní pozorování. Dlouhé udp spojení (wireguard) přes natující router s kernelem 6.5.3, zvenku na stroj v lokální síti. Přes wireguard tečou nějaká data, pár paketů za vteřinu, občas vteřina dvě pauza. Spojení v conntracku routeru přeskakuje z ASSURED do OFFLOAD a zase nazpátek. Je to přitom pořád jedno spojení.
Totéž přes OpenWRT s kernelem 5.xx - spojení je pořád OFFLOAD.
Ty timeouty... Nastavování nf_flowtable_udp_timeout nemá vůbec žádný vliv na stav v conntracku. Tedy do té doby, než nastavím nf_flowtable_udp_timeout na hodnotu rovnu nebo vyšší, než nf_conntrack_udp_timeout_stream. Pak to spojení úplně vytuhne.
Takže, s OpenWRT s kernelem 5.xx na nevýkonném routeru offloading pomocí flowtable zvyšuje propustnost. S kernelem 6.xx to něco dělá, pro některá spojení to skutečně offloaduje, ale nedá se na to spolehnout. Ale vzhledem k tomu, že to běží na normálním počítači, tak je to víceméně fuk, protože ten to výkonově zvládá i bez offloadingu.