Open source download manager Fatrat povstal z popela. Autor k dvacetiletému výročí projektu přidal do vínku podporu nejnovější knihovny libtorrent, rozhraní portoval na QT6, došlo k nahrazení podpory java rozšíření pythonem. Webové rozhraní bylo přepsáno s podporou mobilních zařízení. Aplikaci je taktéž možno zkompilovat bez podpory GUI. Více informací v releases.
Zranitelnost Broccoli2Shell (CVE-2026-111497) v kompresní knihovně Brotli se netýká pouze Node.js. Ohroženy jsou také aplikace využívající HTTP. Knihovnu používají webové prohlížeče, servery i řada dalších aplikací a technologií, například také Python nebo Bun. Identifikace všech zranitelných komponent může být obtížná, protože knihovna bývá součástí dalších softwarových balíčků nebo je přímo začleněna do spustitelných souborů aplikací.
Quad9, švýcarský celosvětově působící neziskový poskytovatel DNS, od 24. listopadu 2026 ukončí své služby ve Francii kvůli soudnímu sporu s katarskou televizní stanicí beIN. Ta požadovala blokování domén, které podle ní nelegálně zpřístupňují sportovní přenosy. Francouzský soud Katarům vyhověl a nařídil (🇫🇷, PDF) Quad9 blokaci zavést, pod hrozbou pokuty 1000 eur denně. Provozovatel příkaz odmítá s tím, že blokace
… více »Článek na blogu APNIC vysvětluje, jak správně vytvářet a používat ASPA záznamy — podepsané objekty v RPKI, které uvádějí, kteří poskytovatelé směrování jsou pro dané autonomní číslo (ASN) oprávněni. Síťoví operátoři je mohou využít k ověřování tras BGP a k odhalování úniků tras či podvržených tras.
Byla vydána (𝕏) verze 8.0.0 open source programu pro prolamování hesel hashcat (GitHub, Wikipedie). Přehled novinek v příspěvku v diskusním fóru a pdf.
Byla vydána (𝕏, Bluesky) nová verze 2026.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 6 nových nástrojů v oficiálním oznámení na blogu.
Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »eth0: RTL8169sb/8110sb
eth1: RTL8169sc/8110sc
Moduly:
r8169 38884 0
mii 6368 1 r8169
rychlosti:
eth0: negotiated 100baseTx-FD flow-control, link ok
eth1: negotiated 1000baseT-FD flow-control, link ok
Těch 100MBit u první je správně, modem umí jen 100MBit LAN (vzhledem k 25MBit internetu dostačuje).
Nevíte náhodou někdo jestli není problém s Realtek ovladači v jádře ? Nějak se mi to nelíbí a už jsme vyměnili 3 desky, ale bohužel realtek byl zatím všude.
Řešení dotazu:
1) Na obou stranách se pomoci utilit "mii-tool" nebo "ethtool" přesvěčte, že máte 1G FD a siťovky jsou natvrdo propojeny kabelem bez switche. Je dobré být v textovém režimu bez grafiky
2) Určitě k měření nepoužívejte iptraf. Silně zkresluje výsledky v momentě, kdy je procesor dosti vytížen (ono záleží na výkonu CPU). Dobrý výsledky jsem měl s programem vnstat, iftop jsem nezkoušel.
3) Při testu si pusťte utilitu "iostat -m 1" a pokud uvidíte, že CPU je vytížen, tak se utilitou "mpstat 1" blíže podívejte čim je vytížen. Určitě výsledky z obou programů sem můžete hodit.
4) Po testu se podívejte na statistiku v "ifconfig". Dulezité parametry jsou errors dropped overruns a musí byt nulové.
5) K měření je dobré nejdříve použít nějaký "UDP bombardovací" prográmek a otestovat zvlášť vysílací strany a pak i proti sobě (nebo využít modulu pktgen, ten vymáčkne z eth driveru opravdu vše). Protože kopírováním souboru se do přenosu zaplítájí další utility (ftp, nfs, samba, atd) a ethernetí driver v tom může být nevině.
6) Co se týče driverů r8169 tak jsou 2. Jeden od výrobce s verzí 6.něconěco.... a druhý co je v jádře pod verzí LK2.3 NAPI (to NAPI šlo kdysi vypínat). U obou není problém vytáhnout 600Mb i na slabším PC (1.6GHz, 512MB RAM). Bohužel už nedokážu říct, u kterého se projevovali nedostatky. Určitě jeden měl problém, kdy se zaseklo vysílání a "TX timeout" špatně resetoval LAN chip.
Pokud chcete ověřit LAN kartu, tak nejříve s UDP paketama nebo ideálně zapojit modul pktgen (jeho zprovozněni chce pevný nervy, ale pokud máte připraveny skripty, tak je to už rutina)
eth0: negotiated 100baseTx-FD flow-control, link ok eth1: negotiated 1000baseT-FD flow-control, link ok
2) - nepoužívám, použil jsem FTP přenos (proftpd + win klient)
3) - je to jádro Conroe, vytížení bylo průměrně 0.7% jednoho ze dvou jader
4) - errory & dropps = 0
5) - můžu použít cokoli, scp, ftp, samba, nfs ... rychlost neměnná, rozdíl v rychlosti SAMBA vs. FTP je cca 10% kvuli režii
6) - já používám od výrobce poslední :( ... PC Intel Celeron-Dualcore 2.5GHz (Conroe), 2GB RAM, 64bit Ubuntu.
Můžete prosím otestovat to pomocí UDP. Samotný test přenosu souborů přes služby ftp, nfs či cokoliv jinýho je opravdu o ničem. Klidně použijte utilitu ttcp
Např.: "dd if=/dev/zero bs=1M | ttcp -t -u -p 5001 vzdálené_IP"
Klidně místo dd dejte "cat opravdu_velky_soubor" (ale bude se tam plést režie disku). Příkazy postupně přidávejte, ale s jiným portem -p (jeden příkaz nedokaže až na full zatížit LANku). Zkuste na serveru vysílání, kolik vyždímáte, co CPU a co vysledek ifconfig.
Pak zkuste na serveru rychlost prijmu. Na vzdáleným dejte ty příkazy, ale s IP serveru a serveru spustte třeba (nebo eth v promiskuitním módu):
"ttcp -r -u -p 5001 > /dev/null"
Změřte statistiku hlavně ifconfig jak bude vypadat. Pokud bude DROP na velikých číslech a CPU bude mít pořád leháro, tak problém bude v tom PCI bridgi nebo spíše, že ta Realtek LAN karta se řádně nedomluví s PCI bridgem.
root@xyz:~# lspci 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:08.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 15) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) 00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
eth0: negotiated 100baseTx-FD flow-controlCo vidíš? Tak vidíš.
Co se týče PCI sběrnice, nemáte pravdu, protože se jedná o PCI 2.2 (minimálně) a tam je nejvyšší možná rychlost přenosu 533 MB/s pri použití 66 MHz signalizace. Dále - řadič disků není již připojen k PCI sběrnici, ale k PCI-Express. Zkoušel jsem připojit i externí řadič do PCI sběrnice a rychlost přenosu dat byla kolem 140MB/s, takže zde problém není.
Problémem je 100% ovladač
protože se jedná o PCI 2.2 (minimálně) a tam je nejvyšší možná rychlost přenosu 533 MB/s pri použití 66 MHz signalizaceAFAIK to, ze deska ma PCI 2.2 neznamena, ze nutne podporuje nejvyssi moznou rychlost. Prevazna vetsina mainboardu (az na specializovane serverove) ma stale jen 33 MHz, 32 bit PCI sbernici.
Díky za rady.
Takže zkusit FTP s vhodnou volbou serveru a klienta, ještě lépe NFSS NFS jsem zas ja mel spatne zkusenosti, co se tyce vytizeni linky. FTP je v tomto ohledu spolehlive. Nebo jeste lepe tcpspray + echo/discard server.
Jasně, že vytížení CPU je trochu vyššíTrochy vyssi vytizeni bylo u rtl8139, ktere melo (pry) striktnejsi pozadavky na alignment, takze bylo nutne data navic jednou v pameti kopirovat. O nejakem podobnem problemu u rtl8168/8169) nevim, takze nevidim, proc by melo byt vyssi vytizeni.
... rychlost se nedostala nad 155MBit i při 12ti hodinovém kopírování :(
ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
Dííííky.
Tiskni
Sdílej: