Byly zpracovány a na YouTube zveřejněny videozáznamy z konference LinuxDays 2025.
Na konferenci LinuxDays 2025 byl oficiálně představen nový router Turris Omnia NG.
Přímý přenos (YouTube) z konference LinuxDays 2025, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
V únoru loňského roku Úřad pro ochranu osobních údajů pravomocně uložil společnosti Avast Software pokutu 351 mil. Kč za porušení GDPR. Městský soud v Praze tuto pokutu na úterním jednání zrušil. Potvrdil ale, že společnost Avast porušila zákon, když skrze svůj zdarma dostupný antivirový program sledovala, které weby jeho uživatelé navštěvují, a tyto informace předávala dceřiné společnosti Jumpshot. Úřad pro ochranu osobních údajů
… více »Google Chrome 141 byl prohlášen za stabilní. Nejnovější stabilní verze 141.0.7390.54 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Za nejvážnější z nich (Heap buffer overflow in WebGPU) bylo vyplaceno 25 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
eDoklady mají kvůli vysoké zátěži technické potíže. Ministerstvo vnitra doporučuje vzít si sebou klasický občanský průkaz nebo pas.
Novým prezidentem Free Software Foundation (FSF) se stal Ian Kelling.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za září (YouTube).
Vyšla kniha Počítačové programy a autorské právo. Podle internetových stránek nakladatelství je v knize "Významný prostor věnován otevřenému a svobodnému softwaru, jeho licencím, důsledkům jejich porušení a rizikům „nakažení“ proprietárního kódu režimem open source."
Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Řešení dotazu:
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -d ::1 -j DROP
Jiného nic neblokuji.
ping6 -c 3 -M do -s 1444 www.google.com
PING www.google.com(prg02s12-in-x11.1e100.net) 1444 data bytes
1452 bytes from prg02s12-in-x11.1e100.net: icmp_seq=1 ttl=57 time=55.9 ms
1452 bytes from prg02s12-in-x11.1e100.net: icmp_seq=2 ttl=57 time=59.8 ms
1452 bytes from prg02s12-in-x11.1e100.net: icmp_seq=3 ttl=57 time=48.9 ms
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 48.936/54.908/59.828/4.516 ms
Jako výstřel do tmy naslepo bych doporučoval zkusit na tom serveru/routeru následující:
ip6tables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
To zajistí, že ať je MTU v LAN jakákoliv, SYN směrem ven nebude navrhovat celou LAN MTU (což bývá na WiFi třeba 2700 B, na ethernetu většinou 1500 B, nejsou-li tam jumbo pakety, atp.), ale tweakne to na správnou menší hodnotu, aby se žádná ze stran nesnažila poslat paket, který prostě neprojde.
Tohle by mohl být problém s MTU, který jsem už párkrát viděl a který se projevuje naprosto přesně tím, co je napsáno v dotazu — všechno zdánlivě prochází až do té chvíle, než se z jakéhokoliv důvodu (obrázek, kryptografický protokol) začnou generovat pakety o velikosti těsně pasující do MTU nebo (v případě PPPoE) překračující MTU. Protože se IPv6 prostě nefragmentuje (skoro, většinou, až na pár hodně zvláštních překvapení), je jasné, že na tohle doplatí mnohem snáze než IPv4.
A mimochodem, výše uvedený příkaz s iptables
místo ip6tables
se může hodit také pro IPv4 — zlepší totiž throughput i latenci právě v situacích, ve kterých by se jinak fragmentovalo na velké počáteční kusy paketů a malé zbytky.
Protože se IPv6 prostě nefragmentuje (skoro, většinou, až na pár hodně zvláštních překvapení)
Tak tohle jsem si kdysi taky myslel…
A byla to pravda.
To složení fragmentů dohromady proběhne ještě předtím, než to čte Wireshark?
Rozhodně ne. Pokud to tedy někdo neposkládá ještě předtím, než to vůbec přijde na ten stroj (což by se ale u IPv6 stát nemělo).
strace -e network
na případné rozdíly v práci se sítí.
ETHTOOL_OPTS="-K $DEVICE gro off"
proč je offloading vůbec nastavený tak, aby to nefungovaloPáč woe přece ten offloading je hrozně kchůůl, psali to v marketingovym letáku, a ještě k tomu ušetříš asi 0.0000000000023% výkonu CPU a to se hrozně vyplatí!!!
u routeru to zlobíTo je přesně to, co mě zajímá. Popis toho, co se stane jinak, jaké to má důsledky, a proč to neprojde.
router by měl pouze přehazovat pakety mezi rozhraníma a neměl by je nijak upravovat.Třeba na OpenBSD se běžně používá TCP proxying pokud vím. Sice je to technologicky trochu něco jiného, ale taky je to zásah do paketů.
Tiskni
Sdílej: