Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
mám dvě připojení a potřebuji aby každé ze dvou navázaných spojení šlo přes jiného ISP.
Našel jsem šikovný návod jak toho dosáhnout.
Označkoval jsem si tedy pakety s cílovým portem 60353 a 60354 značkou 100 resp. 101:
debian:~# iptables -L -t mangle Chain PREROUTING (policy ACCEPT) target prot opt source destination MARK udp -- anywhere anywhere udp dpt:60353 MARK xset 0x64/0xffffffff MARK udp -- anywhere anywhere udp dpt:60354 MARK xset 0x65/0xffffffff MARK tcp -- anywhere anywhere tcp dpt:60353 MARK xset 0x64/0xffffffff MARK tcp -- anywhere anywhere tcp dpt:60354 MARK xset 0x65/0xffffffff
Vytvořil jsem si dvě routovací tabulky podle defaultní brány a udělal pravidlo které pošle označkované pakety na příslušnou bránu:
debian:~# ip route ls table cdma default via 10.160.3.42 dev ppp1 debian:~# ip route ls table umts default via 10.6.6.6 dev ppp0 debian:~# debian:~# ip rule ls 0: from all lookup local 32764: from all fwmark 0x65 lookup cdma 32765: from all fwmark 0x64 lookup umts 32766: from all lookup main 32767: from all lookup default debian:~#Problém je, že když smažu defaultní routu z hlavní routovací tabulky, tak spojení vůbec nenavážu. Např. tcptraceroute píše "Network is unreachable".
Smazat default route z tabulky main není moc dobrý nápad, protože potom neoznačkované pakety nebude možné směrovat vůbec. Pochybuji, že byste veškerý provoz chtěl posílat výhradně jen na ty dva (resp. čtyři) porty, co třeba DNS dotazy?
Ještě jeden nápad: nezkoušel jste to spojení navazovat ze svého počítače? Pak by byl problém v tom, že lokálně generované pakety neprocházejí řetězcem PREROUTING.
A proč to dělám?
Potřebuju "spojit" dvě pomalá internetová spojení do jednoho rychlejšího.
To bohužel nepůjde, jde o počítač bez veřejné adresy. ... ještě mě napadlo že by to mohla dělat cache routovaci tabulky
To bohužel nepůjde, jde o počítač bez veřejné adresy
Jak to souvisí s tím, na co reagujete?
Jestli lokálně generované lokálně neprocházejí chainem PREROUTING tak se nemůžou označkovat a tudíž nepůjdou na správnou bránu - to by to celé vysvětlovalo.
Budu to moct vyzkoušet až večer, tak jsem zvědav.
Zkusil jsem si oznacit pakety v retezci OUTPUT:
debian:/home/houska# iptables -t mangle -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination MARK udp -- anywhere anywhere udp dpt:60353 MARK xset 0x64/0xffffffff MARK udp -- anywhere anywhere udp dpt:60354 MARK xset 0x65/0xffffffff MARK tcp -- anywhere anywhere tcp dpt:60353 MARK xset 0x64/0xffffffff MARK tcp -- anywhere anywhere tcp dpt:60354 MARK xset 0x65/0xffffffffroutovaci tabulky mam dve a pravidlo mam taky nastavene:
debian:/home/houska# ip route ls table cdma default via 10.160.3.42 dev ppp1 debian:/home/houska# ip route ls table umts default via 10.6.6.6 dev ppp0 debian:/home/houska# debian:/home/houska# ip rule ls 0: from all lookup local 32764: from all fwmark 0x65 lookup cdma 32765: from all fwmark 0x64 lookup umts 32766: from all lookup main 32767: from all lookup default debian:/home/houska#V hlavni routovaci tabulce defaultni routu nemam. OpenVPN i tcptraceroute (oboje zkousene na stejnem portu), hlasi shodne:
debian:/home/houska# tcptraceroute 62.84.145.5 60354 connect: Network is unreachable debian:/home/houska# debian:/home/houska# grep unreachable /etc/openvpn/client1-pri.log | tail -n3 Fri May 15 17:48:11 2009 write UDPv4 []: Network is unreachable (code=101) Fri May 15 17:48:13 2009 write UDPv4 []: Network is unreachable (code=101) Fri May 15 17:48:16 2009 write UDPv4 []: Network is unreachable (code=101) debian:/home/houska#
OUTPUT v tomto případě bohužel nepomůže, protože tím paket prochází až poté, co se rozhodne o jeho směrování (jinak bychom nemohli znát odchozí rozhraní). Jako náhražku by v tomto případě mělo být možné použít akci ROUTE netfilteru.
To jste mě moc nepotěšil ... ze zdrojáků debianu byla podpora z netfiltru odstraněná na podzim 07 :( vrrr
Každopádně díky moc za pomoc.
Nasel jsem patch-o-matic, ktery je bohuzel dlouho neudrzovany.
Pak jsem objevil xtables-addons a nebo zde, ktery se tvari jako nastupce P-O-M a je docela cerstvy a udrzovany. Bohuzel zatim nepodporuje -j ROUTE. Nedalo mi to a napsal jsem do konference zda se tato podpora chysta.
Vyvojar xtables-addons mi odpovedel ze po omarkovani je paket znovu routovan ... coz odporuje me zkusenosti.
... tak uvidimeVyvojar xtables-addons mi odpovedel ze po omarkovani je paket znovu routovan ... coz odporuje me zkusenosti.
Takhle to určitě funguje, pokud dojde ke změně cílové adresy v nat.OUTPUT (jinak by celý ten řetězec neměl smysl). Některé zdroje tvrdí, že se totéž děje i při změně značky v mangle.OUTPUT, ale když jsem to kdysi zkoušel, nechovalo se to tak. Jestli budu mít čas, zkusím se na to podívat ještě jednou.
Ještě poznámka k tomu, co jste psal dříve: pokud by problém způsobovala směrovací cache, mělo by stačit ji vyprázdnit (ip route flush cache).
Díky
podle tohoto obrázku by se tak dít mělo
poradíte mi jak to ozkoušet?
Tak jsem to právě vyzkoušel a zdá se, že to tak opravdu funguje. Použil jsem topologii podle obrázku v příloze. Na routeru 83 je v tabulce main pro síť 10.0.23.0/24 směrování přes gateway 10.0.11.84. Když přidám
ip route add 10.0.23.0/24 via 10.0.10.85 table 100 ip rule add priority 1000 fwmark 1 lookup 100 iptables -t mangle -A PREROUTING -m length --length 0:500 -j MARK --set-mark 1
a zkusím se podívat, jak chodí pakety z 10.0.21.82 na 10.0.23.88, tak podle očekávání "dlouhé" chodí dál přes 84, ale "krátké" přes 85. To se ale týká pouze paketů z 10.0.21.0/24, lokálně generované (tj. ping přímo z 83) podle očekávání dál chodí všechny přes 84. Jakmile jsem ale přidal stejné pravidlo i do chainu OUTPUT:
iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 1
začaly se i lokálně generované pakety (z 83) rozdělovat mezi obě trasy podle délky.
Vyvodil jsem z toho poučení, že aby člověk nebyl za blbce, je dobré čas od času vyzkoušet, jestli to, o čem už léta tvrdí že nefunguje, náhodou mezitím fungovat nezačalo.
Moc děkuju, fakt to funguje.
S vaší pomocí jsem to podle délky taky dovedl rozběhat.
Ještě se v tom zkusim povrtat a pak napíšu nějaký zápis do blogu. Zatim nevim co jsem dělal špatně.
U ip rule jsem nepoužíval prioritu a místo lookup jsem měl table ...
Ještě jednou díky. Máte u mě pivo, čokoládu nebo tak něco, dle vašeho výběru.
Jste pořád v Sot-ftroniku?
U ip rule jsem nepoužíval prioritu a místo lookup jsem měl table
To by nemělo vadit. Klíčová slova lookup a table jsou synonyma a pokud se nespecifikuje priorita, přiřadí se automaticky a stejně bude mezi 0 (kterou má pravidlo, které všechno zkouší vyhledat v local) a 32766 (kterou má pravidlo, které všechno zkouší vyhledat v main).
Jste pořád v Sot-ftroniku?
V tom smyslu, že pro ně dělám lektora, ano. Zaměstnanec ale nejsem (ani jsem nikdy nebyl).
Zjistil jsem ze kdyz to mam rozbehane a odstranim z hlavni routovaci defaultni routu tak to zase zacne rvat Network is unreachable
v strace bude určitě ten syscall vidět...
strace nepomůže.
debian:/home/houska# ip route ls 10.160.3.42 dev ppp0 proto kernel scope link src 10.162.62.199 debian:/home/houska#
Podrobnosti v mailkonferenci netfiltru.
Tiskni
Sdílej: