Všechny aktivity

a je tu verze 1.3.0 🥳 detaily a stažení na githubu ➡️ https://github.com/x-rated/OpenMTR/releases/tag/1.3.0 Hlavní novinka: OpenMTR teď běží nativně i na macOS (Apple Silicon) a na Linuxu (AppImage), ne jenom na Windows. Novinky: - macOS verze - nativní .app balíček pro Apple Silicon, vlastní ikona, vlastní menu bar (About/Quit, Edit, Window), automatické přepínání light/dark podle systému (včetně barvy zvýraznění), instalace přes .dmg - Linux verze - AppImage pro x86_64/aarch64 (potřeba glibc 2.43 nebo novější), po prvním spuštění se sama zaregistruje do systému (desktop entry + ikona), takže se správně zobrazí i v GNOME a podobných prostředích. Detekce systémového tématu (light/dark, barva zvýraznění) přes D-Bus, protože se na to nedá spolehnout přes Qt - Přepsaný a vyladěný síťový engine pro Linux a macOS - ICMP trasování už nezávisí na Windows API, na macOS a Linuxu se používají raw/ping sokety, takže IPv4 i IPv6 tracing funguje stejně na všech platformách Změny: - Jedna sjednocená ikona appky pro všechny platformy a témata (dřív zvlášť light/dark ikona jen na Windows) - Přepracovaný CMake build systém, který zvládá všechny tři platformy najednou Poznámka: - macOS build je jen ad-hoc podepsaný (bez placeného Apple Developer účtu), takže při prvním spuštění je potřeba jednou ručně odblokovat quarantine flag - postup je v README Poděkování: - @Pepe(https://github.com/BKPepe) za vytvoření a vyladění macOS verze a enginu pro macOS a Linux s pomocí Claude.ai - OpenMTR je celý postavený na Claude (Anthropic), pod vedením a s revizí majitele projektu VirusTotal kontrola: Linux AMD64: https://www.virustotal.com/gui/file/98f51c4abd373f90a088970a564c54369b79afafe437d494201ca9f3ee076eee?nocache=1 ✅ Linux ARM64: https://www.virustotal.com/gui/file/a0c81d5e4609662917ddb2dac37797590fa4940d05670bd1d9ff309185d07fe1?nocache=1 ✅ macOS: https://www.virustotal.com/gui/file/861d751155ce266fcf337391f3a1b4e88166c0ecb06ec36fb10d1cb3ff157519?nocache=1 ✅ Windows AMD64: https://www.virustotal.com/gui/file/1de101193d79e898ee294cc9a88de0983220648160a6cb7403509b613b855fcc?nocache=1 ✅ Windows ARM64: https://www.virustotal.com/gui/file/9ea155f03e07bb4310ad16bbe8b6b2c747c6c1fc831ffde56b8a95c9d3c8c53f?nocache=1 ✅

Provozuje tu někdo na kabelu dualstack, Station bridge mode nebo Arris CM3500 s Unifi (cloud) gateway ? Nějaké potíže nebo záludnosti v rozchození ? Četl jsem někde, že jejich implementace IPV6 má mouchy - ale už je to starší údaj.

To je hodně krátkozraký. Tady se lidem zvyšuje nájem, inkasní poplatky, vodný-stočný, . . . byty jsou drahý jak prase (nad tím žasnou už i milionáři), do toho se budou zvyšovat ceny dalších služeb, atd., atd. Jednoho krásnýho volebního dvojdne se ta hromada lidí nase*e a hodí to krajní levici. Protože jim dojde, že už se vyzkoušelo všechno a vždy to šlo do mínusu. Ovšem těm, kteří za to nesou odpovědnost, nabobtnává jejich privátní bankovní konto (ty peníze, co chybí se fakt nevypařily, ani neshořely). Ona jednou lidem dojde trpělivost. Jsou to všechno "spojený nádoby", ať se komu líbí nebo ne.

Už zase zdražení? Vždyť zdražovali v prosinci 2025 (u mě +23,-) a teď zase (+20,-)? Za deset měsíců zdražení o 43,-/měsíc. To si ani nezasloužím takové zlepšování služeb, pane jo.

@Marek-26 neslibuj, vlk taky sliboval 😝 Super, děkuji za informaci. Fingers crossed 🤞🏻 😊 Spustil jsem na NASu tcpdump s filtrem na cílový port 32400 a začal se připojovat z iPhonu přes lokální Wi-Fi. Výsledek? Router ten lokální provoz opravdu natvrdo zahazuje ještě předtím, než vůbec dorazí na kabelový port NASu. Zde je pro zajímavost výcuc z logu (IP adresy jsem pro jistotu anonymizoval): administrator@NAS:~$ sudo tcpdump -i any port 32400 tcpdump: data link type LINUX_SLL2 listening on any, link-type LINUX_SLL2, snapshot length 262144 bytes # 1. Úspěšné spojení zvenčí přes záložní AWS cloud Plexu (SYN paket dorazí bez problému) 16:26:33.953070 eth0 In IP [AWS_PLEX_RELAY_IP].57472 > NAS.32400: Flags [S], seq 2485952717, win 62727, options ... # 2. Úspěšné spojení zvenčí napřímo přes mou veřejnou IPv4 adresu (SYN paket dorazí bez problému) 16:26:34.648135 eth0 In IP [MOJE_VEREJNA_IP_WAN].63016 > NAS.32400: Flags [S], seq 530614783, win 65535, options ... V celém rozsáhlém logu normálně vidím iniciační SYN pakety (Flags [S]), ale výhradně zvenčí z internetu. Z lokálního rozsahu mé Wi-Fi (192.168.0.x) tam nespadlo absolutně nic. Tím si myslím je potvrzeno, že firmware ve Vodafone Ultra Hub 7 dělá agresivní a hlavně nežádoucí filtraci přímo na interním WLAN – LAN mostu. Telefon paket do Wi-Fi sítě bezesporu odešle, ale router ho detekuje a na kabel už nepustí. S tímto jdu rovnou na druhou úroveň podpory. Ještě jednou díky za ten nápad s tcpdumpem! @zajdee Díky za tip Dále jsem na chvíli vyzkoušel vypnout firewall a nepomohlo - byť to pro mě stejně není systémové řešení. PS.: Pokud jsem takto jediný (což dle hovoru s technickou podporou zatím jsem), tak to ani v rámci firmware nebudou řešit.

@royal198 v Praze ty FRITZ!Boxy jsou, s výměnou by neměl být problém.

@Technikus No to nevím, zatím jsem tu jediný co napsal, že si to nenechal líbit a z padesátky platím navíc jen dvacku. A těm co nevědí a jsou zde na foru by ta většina místních měla poradit a ne se jim vysmívat...

Okay, vyzkouším a poreportuju. Jen ještě UPDATE. Někdo jiný zde - https://www.techforum.cz/topic/64361-výměna-modemu-bude-fritz/ minulé úterý psal, že naopak mu chtějí Vodafone Station měnit za Fritz - divný když už se vlastně nenabízí a mělo by se měnit na HUB 7. Tak jsem hned volal na linku a rezervoval jsem si výměnu HUB 7 na Fritz s tím, že je šance, že mi budou volat, že už to není možné. Zároveň jsem se ptal, jestli kdybych si koupil vlastní, jestli je to OK a teoreticky ano. No uvidíme... Ale s*aní s tím se strašný...

Co test tcpdumpem? Je mozne na synology spustit tcpdump a podivat se, jestli dorazi z wifi klientu SYN pakety na tento (blokovany) port? Pokud nedorazi, je to jasny a neodvratitelny dukaz, ze VF router filtruje provoz.

Hele kdybych si ten AVM Fritz!Box koupil sám za plnou cenu, což dle dnešního infa z linky by mělo být možné, ví někdo proces registrace v rámci Vodafone, DOCSIS 3.1 atp.? Jelikož na lince se dostanu většinou na paní, co vůbec neví, co AVM Fritz!Box je :-( UPDATE: Tak prý to vyzkouší a kdyby ten FritzBox nebyl volný, tak mi budou volat. Alternativně si ho možná koupím sám za těch skoro 8k :D PS.: Vím, dát si pozor na to, aby nebyl vázaný na nějakou předešlou smlouvu u Vodafone v DOCSIS

Koukám že už ani u Wernera nejsou skladem.

Jeste je dalsi moznost koupit si prevodnik Arris CM3500 nekde na eshopu. Vodafon vlastni modem snad umi zaregistrovat. Treba tady: https://www.werner-electronic.de/kabelmodem-arris-cm3500-b-ce-25-gbps-lan-port

Naopak si myslím, že vetšina místních ví co a jak a tak zkusí cenu služeb optimalizovat. A ti, kteří nevědí, ať si připlatí.

Smutné je, že většina z vás si to nechá líbit a jen si stěžuje a pláče v internetových diskuzích.

BBC Player zamíří na Prima+, nabídne přes tisíc hodin britského obsahu https://www.mediaguru.cz/bbc-player-zamiri-na-prima-nabidne-pres-tisic-hodin-britskeho-obsahu

U mě internet zdražili Internet Basic o 75kč. 🫤

Technický report: Nežádoucí filtrace paketů na WLAN rozhraní (Vodafone Ultra Hub 7) Základní shrnutí problému: Po přechodu na 2Gbit tarif a výměně routeru za Vodafone Ultra Hub 7 dochází k systematickému blokování specifických TCP portů (konkrétně portu 32400) při vnitřním směrování provozu z bezdrátových klientů (WLAN) na kabelově připojený server (LAN). Komunikace LAN–LAN funguje bezchybně. 1. Topologie sítě a HW vybavení Router / Gateway: Vodafone Ultra Hub 7 (výchozí brána, DHCP a DNS server: 192.168.0.1). Server: Synology NAS DS124, připojený fyzicky přes 1Gbit ethernet port přímo do routeru. Přiřazena statická lokální IP adresa: 192.168.0.44. Běžící služby: DSM (port 5000), SMB (port 445), Plex Media Server (port 32400), lokální VPN server. Klienti: Apple Mac a iPhone, připojeni výhradně přes Wi-Fi (WLAN). 2. Detailní popis závady Plex Media Server naslouchající na lokální adrese 192.168.0.44:32400 je z Wi-Fi klientů absolutně nedostupný. Prohlížeč i nativní aplikace hlásí timeout (spojení selhalo). Kvůli nedostupnosti přímého lokálního spojení se aplikace (např. iOS Plex App) pokouší o asymetrický obchvat přes internetové servery (Plex Relay), což vede ke stavu „Remote Connection“, degradaci kvality streamu a vynucování předplatného, ačkoliv se klient i server nacházejí ve stejné podsíti (192.168.0.0/24). 3. Provedená diagnostika a vyloučení chyb na straně uživatele K izolování problému na stranu routeru byly provedeny následující testy: A. Testy fyzické vrstvy a základní konektivity: NAS byl přepojen do jiného LAN portu (z portu 4 do portu 2) – bez změny. Standardní AP izolace (Client Isolation) byla vyloučena: Z Wi-Fi klientů lze NAS bez problému pingnout, funguje přístup do webové administrace (port 5000) i mapování síťových disků přes SMB (port 445). Byl proveden test klientského PC připojeného ethernetovým kabelem – připojení na port 32400 funguje okamžitě a bez problému. Závěr: Závada se projevuje výhradně při průchodu paketů mezi WLAN čipem a LAN switchem uvnitř routeru na nestandardních portech. B. Testy na straně klienta (macOS / iOS): Vypnuto skrývání MAC adresy („Soukromá adresa Wi-Fi“) pro vyloučení chyb při IP bindingu. Vypnuto Apple Private Relay (Soukromý přenos) a „Omezit sledování IP adresy“, aby nedocházelo k maskování lokálních DNS požadavků a směrování přes Apple proxy. Proveden test přes mobilní data s aktivním VPN připojením do domácí sítě. Jakmile je vynecháno WLAN rozhraní routeru, Plex aplikace na iOS se okamžitě lokálně spojí se serverem. C. Testy bezdrátové sítě routeru (Band Steering): Sloučená Wi-Fi síť (Smart Wi-Fi / Band Steering) byla manuálně rozdělena na samostatná 2.4 GHz a 5 GHz SSID. Při exkluzivním připojení klienta pouze na 2.4 GHz síť zůstává port 32400 nadále blokován. D. Testy na straně serveru (Synology NAS): Kompletně deaktivován firewall v Synology DSM – bez změny. Zkontrolován Auto-Block list v Synology, žádná lokální IP adresa není blokována. Ověřeno naslouchání služby Plex na všech síťových rozhraních (rozhraní nastaveno na „Any“). E. Vyloučení vlivu směrování (Port Forwarding / NAT) a potvrzení veřejné IP: Pravidlo Port Forwarding pro port 32400 (TCP) směrem na lokální IP 192.168.0.44 je na routeru nastaveno a plně aktivní. Vzdálený přístup z internetu (z WAN do LAN) funguje naprosto bezchybně. To je plně umožněno tím, že disponuji plnohodnotnou veřejnou IPv4 adresou a funkce Vzdálený přístup (Remote Access) je v Plex Media Serveru korektně aktivována. Při lokální komunikaci (z WLAN do LAN) ovšem provoz vůbec nedosáhne k NAT/Firewall vrstvě routeru. Komunikace probíhá výhradně na interním mostě (bridge) mezi Wi-Fi čipem a integrovaným LAN switchem. Závěr: Diagnostika potvrzuje, že k cílenému zahazování paketů dochází přímo na vnitřním WLAN–LAN mostě. Veřejná IP adresa a nastavení vzdáleného přístupu potvrzují správný chod serveru, zatímco uživatelská pravidla pro přesměrování portů na interní lokální blokaci logicky nemají žádný vliv. F. Absolutní vyloučení chyb v síti klienta/serveru (Test přes lokální VPN tunel): Test: Na Wi-Fi klientovi bylo aktivováno připojení do VPN tunelu (OpenVPN), jehož server běží přímo na totožném NASu (192.168.0.44). Po připojení do VPN Plex z Wi-Fi okamžitě a plnohodnotně funguje. Vysvětlení: Tento jev 100% potvrzuje nežádoucí filtraci na routeru. VPN tunel zapouzdří (enkapsuluje) veškerou síťovou komunikaci (včetně požadavků na port 32400) do šifrovaného spojení pod standardním VPN portem. Firmware Ultra Hubu 7 na Wi-Fi rozhraní vidí pouze povolený zapouzdřený provoz, který na LAN propustí. Jakmile NAS tento paket přijme a lokálně dešifruje, požadavek na vnitřní port 32400 se bez problému zpracuje. Závěr: Router prokazatelně a cíleně provádí inspekci paketů a zahazuje specificky nezapouzdřený provoz na portu 32400 při přechodu z Wi-Fi na kabel. 4. „Ultimátní důkaz“ chybné inspekce paketů (Reverzní proxy test) K finálnímu potvrzení, že router na Wi-Fi provádí nežádoucí L4/L7 filtraci, byl na Synology NAS spuštěn webový server Nginx (Reverse Proxy). Nastavení: Příchozí provoz na portu 8443 (HTTP) byl interně v NASu přesměrován na localhost:32400. Výsledek: Jakmile byl k přístupu z Wi-Fi klienta použit běžnější port 8443, router spojení propustil a webové rozhraní služby běžící na 32400 se okamžitě načetlo. Tento obchvat však nelze využívat trvale, jelikož mobilní operační systémy (iOS App Transport Security) z bezpečnostních důvodů blokují nešifrovaný HTTP provoz na nestandardních portech u aplikací, které nemají možnost akceptovat self-signed certifikát. 5. Závěr a požadavky na L2/L3 podporu Na základě výše uvedené komplexní diagnostiky je zcela zřejmé, že NAS, klienti i lokální síťová logika fungují naprosto správně. Problém tkví v agresivním blokování nestandardních portů na Wi-Fi rozhraní (WLAN) firmwarem Vodafone Ultra Hub 7.

Mám Fritzbox a Plex na Synology a všetko mi funguje úplne v pohode.

Jako dočasně, jestli to bude fungovat, nebo napořád? Já nemám nikde další FW, který by mě chránil.... Tak jsem strávil skoro 60 minut na lince technické podpory. Ještě jednou bych chtěl moc poděkovat operátorovi, který mé dotazy ochotně tlumočil na vyšší level IT a aktivně se snažil vše prověřit a vyzkoušet. Nakonec se ale potvrdilo to, k čemu jsem dospěl sám – problém bude pravděpodobně ve firmwaru samotného Vodafone Ultra HUB 7. Jsem zřejmě první, kdo tohle řeší. Důvody jsou nejspíš dva: Ultra HUB 7 zatím mezi lidmi moc rozšířený není a ti, co mají podobně specifické požadavky, většinou používají vlastní router za modemem a řeší si síť po svém. Jelikož IT podpora tato fóra sleduje, budu sem průběžně psát výsledky dalších pokusů. Je ale dost možné, že se v dohledné době dočasně vrátím k Vodafone Station WiFi 6, kde s tím žádný problém nebyl. Pokud by měl někdo další stejný problém, tak budu rád, když se podělí o svoje zkušenosti. Pokud nás bude hodně, tak se to třeba bude řešit v rámci FW update někdy v budoucnu. Díky Jen ještě info - toto taky na zákaznické lince padlo, ale už jich asi moc nebude a není to pro mě "systémové" řešení. BTW jsem se ptal, jestli je možné si sehnat vlastní zařízení a vlastně to možné je, jen je potřeba najít takové, které splňuje cca 9 stránkové požadavky a to se samotnému Vodafone povedlo vlastně právě jen s tím AVM Fritzbox, který fungoval jako přechodné řešení než byl ready Vodafone Ultra HUB 7.

Zkusil bych na chvilku vypnout FW na tom routeru. Mně takto blokoval automatické občerstvování certifikátů na webech, které za ním provozuji na RPI.

Hele upřímně? Zavolám na linku, jestli se s tímto dá v rámci HUB 7 něco dělat a pokud ne, tak raději původní router klidně na 2Gbit tarifu... Já bych to teoreticky klidně řešil tím workaroundem, kdyby alespoň ta "marketovaná" Wi-Fi 7 fungovala, ale vlastně to neumí nic jiného 2,5Gbit port vs Vodafone Station WIFI 6 a jen s tím mám větší problémy. Četl jsem něco o Secure Net? Neví jestli to může být tím a jestli to lze nějak deaktivovat per user....

U mě tež zdražení mobilního tarifu asi o 40Kč.

Zkus se u Vodafonu zeptat zda by ti ho nevyměnili za modem AVM Fritzbox, umí také 2 Gbit a má mnohem širší možnosti nastavení, naopak Ultra hub je na tomto docela bídně. Návrat k Vodafone stationu by byl možný zřejmě jedině pokud bys přešel zpět na pomalejší tarif.

Hele jelikož mi Ultra HUB 7 neposkytne primární benefit a to WiFi7, protože to reálně neumí a ještě mi doma totálně rozbil "PLEX" ekosystém na lokální síti, bude možné si zažádat zpět o Vodafone Station WiFi 6 byť mám 2Gbit tarif? Vlastně nevidím v tomto zařízení žádný benefit (ten 2Gbit na LAN nutně nepotrebuji). Neumí ani bridge a nechci další zařízení, co bude ročně žrát 200kWh+.

Ahoj všem, řeším problém po výměně routeru za nový Vodafone Ultra Hub 7. Na zařízeních připojených přes Wi-Fi (iPhone, Mac) mi přestal v lokální síti správně fungovat PLEX server běžící na Synology NAS. Aplikace PLEX vyhodnocuje Wi-Fi klienty jako „vzdálené / nepřímé spojení“ a vyžaduje předplatné za vzdálený přístup, případně se lokálně vůbec nespojí. Srovnání starého a nového routeru: Původní router (Vodafone Station WiFi 6): PLEX server na Synology NAS (192.168.0.44). Všechna zařízení na kabelu i na Wi-Fi fungovala bez jediného problému v přímém lokálním režimu (šifrovaně přes HTTPS). Nový router (Ultra Hub 7): Ponechal jsem identický IP rozsah (192.168.0.x/24), masku, bránu (192.168.0.1) i statickou IP pro NAS (192.168.0.44). Zařízení na kabelu (PC, TV) fungují dál bezchybně. Problém se týká výhradně klientů na Wi-Fi. Identifikace problému a co jsem ověřil: Fyzická konektivita LAN–WLAN je v pořádku: Z Wi-Fi se na NAS bez problému dostanu – webové rozhraní Synology DSM ([http://192.168.0.44:5000](http://192.168.0.44:5000)) i síťové disky přes SMB reagují okamžitě. Blokování DNS Rebindingu: PLEX pro přímé zabezpečené lokální spojení používá domény ve tvaru *.plex.direct, které překládají veřejný požadavek zpět na lokální IP (192.168.0.44). Ultra Hub 7 vystupuje pro klienty jako výchozí DNS server (192.168.0.1) a tyto DNS dotazy blokuje z důvodu ochrany proti DNS Rebind. Nemožnost změny DNS v DHCP: V administraci Ultra Hubu 7 v sekci Nastavení sítě chybí možnost nastavit vlastní DNS servery pro DHCP (změnu na 1.1.1.1 nebo 8.8.8.8). Router natvrdo všem zařízením v síti podstrkuje jako DNS sám sebe. Pokud na konkrétním zařízení na Wi-Fi přenastavím DNS ručně nebo v PLEXu vynuťte nezabezpečené nešifrované HTTP spojení na portu 32400, komunikace projde. Není to ale systémové řešení pro celou domácnost a všechna zařízení. Moje dotazy na komunitu: Existuje v administraci Ultra Hubu 7 možnost vypnout ochranu proti DNS Rebindingu nebo povolit výjimku pro doménu plex.direct? Lze nějakým způsobem přinutit DHCP server v routeru, aby klientům distribuoval vlastní DNS servery namísto IP adresy routeru? Předem díky za jakékoliv tipy a rady! Hele tak nakonec vyřešeno způsobem, který se mi upřímně moc nelíbí, ale uvidíme. V DSM V Plex A funguje i aplikaci například pro MacOS... UPDATE: Na iOS to ale zprovoznit nelze...