zajdee

Tam zadna ztrata neni. Pokud je loss na nekterem z hopu, ale nepropise se do zbytku cesty, tak je to jen ICMP policing (routery se chrani pred velkym mnozstvim ICMP paketu a na cast z nich neodpovidaji). Od hopu "ae29-100-ucr1.pra.cw.net" je to beze ztraty, stejne tak cilovy server je beze ztraty. Compal ma krome mnohych dalsich chyb i tu vlastnost, ze ICMP radi do jine tridy nez UDP a TCP, takze traceroute s ICMP nemusi uplne verohodne odrazet skutecny stav linky a zvyseny jitter (ten se muze projevit jen nekdy, podle toho, jak je zrovna chipset Compalu vytizeny). Osobne bych to resil s VF jako reklamaci sluzby - muze byt treba problem s kvalitou signalu (Compal je na to citlivy) nebo proste jen problem s Compalem v case, kdy je v siti vetsi provoz. Pro gaming bych osobne doporucil spis prejit na VF station v bridge mode a za tim nejaky skutecne schopny router... IP adresu serveru z WinMTR bohužel nepoznám, ale vyzkoušel jsem si mtr na předposlední hop. Co mě na tom WinMTR výpisu překvapuje (ale vlastně ne, je to skrz Compal) je sloupec "Wrst", tedy nejhorší výsledek z celého měření. MTR ode mě z optiky CETINu se službou od T-Mobile vypadá takhle ("Wrst" je 20 milisekund, jen o kousek horší, než "Average"; linuxový MTR navíc ukazuje i velmi malou odchylku, tj. StDev [Standard deviation]). Loss 0. 2 % připisuju ICMP policingu routerů na cestě. # mtr -c600 -w -b po2.agr1-dedi-m1.bb.as24961.net Start: 2022-01-29T23:01:23+0100 HOST: Loss% Snt Last Avg Best Wrst StDev 3.|-- 2001:af0:f::1db 91.5% 600 7.1 7.0 6.2 7.6 0.2 4.|-- 2001:af0:f::1da 47.5% 600 7.5 7.3 6.8 7.8 0.2 5.|-- 2003:0:1309:4030::2 0.0% 600 15.2 14.9 14.1 15.5 0.2 6.|-- 2003:0:1309:4030::1 25.0% 600 15.5 735.7 14.6 5941. 1326.4 7.|-- ??? 100.0 600 0.0 0.0 0.0 0.0 0.0 8.|-- 2003:0:f00::eb 0.2% 600 17.6 17.5 16.8 18.0 0.2 9.|-- po6.core2-dus3.bb.as24961.net (2001:4ba0:ffe9:17::1) 0.2% 600 19.5 19.3 18.3 19.9 0.2 10.|-- po2.agr1-dedi-m1.bb.as24961.net (2001:4ba0:ffe9:19::2) 0.2% 600 19.3 19.3 18.6 20.7 0.2 Z přípojky VF/DS-Lite (+ černý Compal v režimu Router): # mtr -c300 -w -4 -b po2.agr1-dedi-m1.bb.as24961.net Start: Sat Jan 29 23:15:53 2022 HOST: Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway (192.168.0.1) 0.7% 300 13.1 9.4 2.2 213.6 15.1 2.|-- cz-prg01a-rt1.net.vodafone.cz (84.116.220.17) 0.3% 300 17.5 25.2 13.0 419.8 33.7 3.|-- cz-prg01a-ra4-ae23.net.vodafone.cz (84.116.223.26) 0.3% 300 24.9 26.7 14.1 337.0 30.7 4.|-- ??? 100.0 300 0.0 0.0 0.0 0.0 0.0 5.|-- te2-2.sitr00i.vodafone.cz (217.77.160.45) 86.3% 300 17.6 24.5 14.4 50.7 8.6 6.|-- ae8-100-ucr1.czs.cw.net (195.2.12.41) 0.3% 300 23.7 22.4 13.8 87.3 10.0 7.|-- ae10-ucr1.pra.cw.net (195.2.8.74) 0.3% 300 19.6 23.0 14.8 77.1 7.5 8.|-- ae15.cr3-prg1.ip4.gtt.net (46.33.79.241) 0.0% 300 21.2 25.6 13.8 399.0 28.2 9.|-- ae16.cr3-dus1.ip4.gtt.net (89.149.186.61) 0.3% 300 33.3 38.6 24.2 504.5 35.5 10.|-- 76.74.9.170 0.3% 300 28.5 34.0 24.5 416.4 26.7 11.|-- po6.core2-dus3.bb.as24961.net (62.141.47.86) 0.3% 300 28.6 34.0 25.6 333.0 20.0 12.|-- po2.agr1-dedi-m1.bb.as24961.net (62.141.47.157) 0.0% 300 31.6 38.2 26.1 557.2 42.5 Z přípojky VF/IPv4-only (+ bílý Compal v režimu Bridge): # mtr -c300 -w -4 -b po2.agr1-dedi-m1.bb.as24961.net Start: 2022-01-29T23:15:55+0100 HOST: Loss% Snt Last Avg Best Wrst StDev 1.|-- _gateway (192.168.1.1) 0.0% 300 0.7 0.7 0.7 1.2 0.1 2.|-- ??? 100.0 300 0.0 0.0 0.0 0.0 0.0 3.|-- ip-86-49-55-193.net.upcbroadband.cz (86.49.55.193) 0.0% 300 8.6 16.1 7.1 177.8 23.2 4.|-- cz-prg01a-ra4-vla2156.net.vodafone.cz (84.116.221.225) 0.0% 300 158.0 15.6 7.7 158.0 20.5 5.|-- strlG01-vla2121.net.vodafone.cz (84.116.223.121) 94.0% 300 8.3 9.3 7.6 17.7 2.2 6.|-- te2-2.sitr00i.vodafone.cz (217.77.160.45) 85.0% 300 8.1 15.4 7.9 125.6 21.6 7.|-- ae8-100-ucr1.czs.cw.net (195.2.12.41) 0.0% 300 8.3 17.0 7.7 159.2 23.3 8.|-- ae10-ucr1.pra.cw.net (195.2.8.74) 0.0% 300 9.8 17.4 7.9 167.1 21.7 9.|-- ae15.cr3-prg1.ip4.gtt.net (46.33.79.241) 0.0% 300 8.6 16.5 7.7 210.0 23.9 10.|-- ae16.cr3-dus1.ip4.gtt.net (89.149.186.61) 0.0% 300 23.9 27.9 18.1 213.1 25.2 11.|-- 76.74.9.170 0.0% 300 19.8 26.9 17.9 186.1 25.3 12.|-- po6.core2-dus3.bb.as24961.net (62.141.47.86) 0.0% 300 19.3 27.0 18.1 205.3 25.7 13.|-- po2.agr1-dedi-m1.bb.as24961.net (62.141.47.157) 0.0% 300 18.4 19.9 17.6 36.4 2.5 Ještě jedna otázka: nemáte náhodou přípojku v režimu DS-Lite? Od léta 2017 jsou všechny nově zřizované přípojky pro domácnosti v režimu DS-Lite, dokud si zákazník neřekne o změnu na IPv4-only. Zkuste http://www.test-ipv6.cz/ (raději z více zařízení) a pokud se objeví, že je IPv6 dostupná, tak je to přípojka v režimu DS-Lite. Proč je DS-Lite problém? Protože DS-Lite/NAT brána u operátora (která zajišťuje ukončení IPv4 tunelů v DS-Lite) se snadno vytíží (v Německu vytížení DS-Lite/NAT brány operátora způsobovalo dost pozdvižení) a večer může způsobovat popisované chování. Řešením by mohlo být přepnutí služby do režimu "IPv4-only".

@Lizardor jaky byl ten puvodni modem a jaky je ten novy? Pokud ten stary nebyl compal a ten novy je compal (cerny nebo bily, je to jedno), tak to dost mozna muze byt tim modemem. Jeho chipset je hrozny krap, ktery mimo jine zpusobuje vysoky jitter (kolisajici latence) a casto i ztraty paketu (hlavne v rezimu pripojky "IPv4-only" a aktivnim modu "bridge").

Dobré odpoledne, proč na tohle fórum nelze vkládat odkazy na Twitter? Když to zkusím, dostanu chybu, na obrázku v příloze.

Ohledně toho variabilního symbolu na webu VF (https://www.vodafone.cz/overeni-udaju/), bylo tam "Variabilní symbol je stejný jako číslo vaší exUPC smlouvy, jen nemá na konci číslici 1." Nahlašoval jsem to 20. 1., asi už to stihli opravit, protože teď je tam: "Variabilní symbol je stejný jako číslo vaší exUPC smlouvy, jen má na konci číslici 1."

Hlaseni o technicke chybe tam bylo uz pred tremi tydny, kdy jsem to zkousel naposled (tesne pred prevodem od UPC k VF). Nejspis dlouhodobe nereseny problem. 🤔

Na iOSu hazi aplikace po pripojeni displeje pres HDMI chybu MT1550. (odkaz na twitter se screenshotem sem primo vlozit nejde, forum vrati chybu)

Okrem OpenWRT DS-Lite podporovaly D-Linky kdysi davno, ale nevim, jaka je situace ted. Rychly pruzkum Googlem naznacuje, ze DS-Lite podporuji i TP-Linky a ZyXELy (nektere). Neni to rozhodne bezne, plny dualstack a modem v bridge mode by pro pokrocile uzivatele byl mnohem atraktivnejsi a provozovatelnejsi rezim.

Vodafone v Revnicove nemel ani 3G ani kapacitni LTE vrstvy. Pokud se tam objevi 5G, bude to spis jen 5G v pasmu 700 MHz.

Vodafone je posledni operator, ktery bonding na siti CETINu neumi. Je to ostuda. (Taky neumi IPv6 na DSL. Dalsi ostuda.)

Pokud lze zvenku pingnout verejnou IP, je to nejspis spravne pripojene. Jakym zpusobem testujete ping ven? Primo z terminalu toho mikrotiku? Nebo z lokalni site za mikrotikem? Jak vypadaji pravidla pro firewall a NAT na Mikrotiku? Pridejte sem screenshoty z interfaces, ipv4 addresses, firewall, traceroute 8.8.8.8 z toho mikrotiku a z pocitace za mikrotikem.

Ano, takhle to jde, ale to je mimo moznosti bezneho uzivatele. 🙂

Loni na VF station moznost spravy statickych rout nebyla. Na Compalu tusim taky neni.

Liberty Global se zbavuje dceřinných společností už delší dobu. Je jen otázkou, kdy (a komu) prodá slovenskou dceru.

Tak muzete mit firewall pro ethernetove rozhrani a ne pro wifi rozhrani, proto to po prepojeni funguje. 🙂 zkusil bych spis vyzkouset pripojit jiny pocitac kabelem a ssh mezi nimi. pripadne sitarska ladici klasika - udelejte snapshot tcpdumpem a poslete nam ho sem: 1) na pocitaci s kabelem spustte "sudo tcpdump -v -w dump.pcap -i nazevrozhraniskabelem tcp port 22" 2) na pocitaci s wifi se zkuste nekolikrat pripojit na ssh pocitace s kabelem 3) zastavte tcpdump a poslete sem vysledny pcap (predpokladam, ze pc s ssh jsou na linuxu nebo macosu)

A neni mozne, ze Connection refused vraci primo ten SSH demon nebo operacni system (firewall) na pocitaci pripojenem kabelem? Compal router je tupe zarizeni a kabelova LAN a WLAN jsou probridgovane do jedne L2 site. Firewall se uplatnuje smerem do Internetu, e mezi kabelovou LAN/WLAN.

Pokud mate klientske zarizeni s 802.11ax, zkuste, jestli se vam s novym firmwarem (ne)zvedla realne dosahovana rychlost...

S VF station to kvuli absenci bridge rezimu jeste u nas nikdo netestoval... (ktere varianty mate na mysli?)

Omezeni rychlosti se vztahuje na vsechny tunelovaci mechanismy pouzivajici IP protokol 41, tj. 6to4 (automaticke tunely), 6in4 (HE a spol) a 6rd (u nas nikdo neprovozuje). 6to4 ma nad ramec omezeni rychlosti jeste dalsi problemy: - je depreferovano, tj. IPv4 ma vetsi prioritu a operacni system tak IPv6 nebude vyuzivat - je zavrzeno, protoze je velmi nestabilni (https://datatracker.ietf.org/doc/html/rfc7526 a https://www.rfc-editor.org/rfc/rfc6343.txt) Proto je doporuceno 6to4 nepouzivat. Kdo ho nasadi, doslova si pokazi konektivitu z domaci site. Ad volba mezi IPv6 a v4: - browsery implementuji happy eyeballs, tj. pokusi se zaroven pripojit k IPv4 a IPv6 (pouze pokud mate normalni globalni IPv6 adresy, ne 6to4 adresy zacinajici 2002:...) a "prvni rychlejsi pripojeni vyhrava" (https://www.lupa.cz/clanky/happy-eyeballs-aby-uzivatele-pri-vypadcich-netrpeli/); IPv6 dnes dokonce ma i trochu naskok, takze obvykle vyhraje. - happy eyeballs neresi problemy, kdy jedno ze spojeni je vyrazne pomalejsi, tj. v pripade Compalu bude preferovana IPv6 konektivita s nizkou rychlosti

🤷🏻‍♂️Tocime se v kruhu. HE neni 6rd ani 6to4. HE skrz sit UPC/VF vzdy fungovalo. TP-Link ma v GUI bordel a nejspis ho ma i ve firmwaru, kdyz ti najednou zacalo fungovat neco, co ostatnim klientum normalne fungovalo. A v UPC/VF se nemaji cim chlubit, protoze nic novyho nerozchodili. (Problem s rychlosti tunelu skrze Compal zustava.)

Ne, vubec jsi nenapsal, co jsi tedy presne nastavil a co zacalo fungovat. Takze jsi realne nikomu nepomohl, jen tu zmatl ctenare. Budu-li vychazet z prvniho navodu na Googlu, tak TP-Link umi nastavit "6to4" (vyuziva automaticky generovany prefix a dnes je kvuli nestabilite zapovezene) a "6rd" (vyuziva manualne nastaveny prefix a tunelovaci branu). Pokud ti zacal fungovat IPv6 tunel na TP-Linku s IPv6 prefixem a tunelovaci IPv4 adresou HE a nastavenim TP-Linku "6rd", ve skutecnosti jsi nastavil "6in4" tunel k HE. Funguje to diky tomu, ze 6in4 i 6rd pouzivaji shodny transport a lisi se v konfiguraci (parametry pro 6rd dodava operator, tunelovaci server je v jeho siti, IPv6 prefix je z rozsahu operatora a obvykle operator dokaze 6rd nakonfigurovat automaticky a vzdalene; parametry pro 6in4 dodava HE, IPv6 prefix je z rozsahu HE, konfiguruje se rucne). Rozdil je v tom tedy dost vyrazny. Jak jsem psal v prvnim prispevku, v tomhle rezimu to skrze sit UPC vzdycky fungovalo (vuci tunelovacim serverum HE, SIXXS i jinym). Jeste me napadla jedna vec: Mikrotik to ma v GUI taky blbe, ale jinak nez TP-Link. V RouterOSu manualne konfigurovanym tunelum rikaji 6to4, i kdyz se nepouziva automaticky generovany prefix z rozsahu 2002::/16, ale rucne nastaveny prefix a IPv4 protistrana tunelu.

"IPv6 - tunel 6to4" "Tak spolu s pevnou veřejnou IPv4 už funguje i IPv6 (tunel 6to4)" 🤔🤷🏻‍♂️ale nikde jsi to nepsal, no. (HE neni 6rd, ale 6in4.) Dozvime se, co teda presne zacalo fungovat? Pro ostatni ctenare: 6to4 ani 6in4 nevyzaduji krome transparentniho forwardovani zadnou podporu na strane ISP. 6to4 je velmi nestabilni a dnes zavrhovany protokol, nicmene vzdycky byl v siti UPC rozchoditelny (staci mit verejnou IPv4 adresu a spravny router). 6in4 v siti UPC je a vzdy bylo funkcni, jen na Compalu trpi omezenim rychlosti v kazdem ze smeru na ~20 Mbps. 6rd vyzaduje podporu na strane ISP. Krome jineho musi operator v siti mit 6rd tunelovaci server. IPv4 je nativni. Transport IPv6 paketu mezi klientskym routerem a tunelovacim serverem ISP vyuziva IPv4 sit operatora (IPv6 se prenasi po IPv4). Tento rezim UPC nikdy nepodporovalo. DS-Lite (aktualni rezim nasazeni u UPC pro rezidentni pripojky zrizene po cervnu 2017) vyzaduje podporu na strane ISP. Operator musi mit v siti DS-Lite tunelovaci server. IPv6 je nativni. Transport IPv4 paketu mezi klientskym routerem a tunelovacim serverem ISP vyuziva IPv6 sit operatora (IPv4 se prenasi po IPv6, opak 6rd).

@Adolf.Shitler 6to4 (puvodni prispevek) neni 6rd. UPC 6rd nevyuzivalo vubec. Nativni dual-stack pak neni ani 6to4 ani 6rd. 6in4 (managovane tunely - HE tunnelbroker.net a spol) fungovaly vzdycky, pokud mel uzivatel modem v bridge. Neni duvod, aby zacaly fungovat az ted. Jak presne ma vypadat ta konfigurace s 6rd? Ja velky prefix uzivatel dostane, jaky 6rd server ma pouzit? Je a pro IP protokol 41 bohuzel bude. Jedina cesta z tunelu je pomoci jineho modemu.

Co znamena "funguje"? On nekdy byl s touhle konfiguraci problem (jiny nez pomala rychlost)?

Napis CETIN na chodniku je tzv. vytyceni site (mely by tam byt vyznacene i dalsi site jako elektrina, plyn, voda) a slouzi k informovani stavebnika, aby si v tech mistech daval vetsi pozor a site neposkodil. Nemusi to nutne znamenat, ze tam probiha stavba site elektronickych komunikaci. Jak vlastne vypadaji ty "ctyri kabely ve sklepe"? Uz ten pocet je zvlastni. Pokud by to ale byly treba jen prazdne HDPE trubky, ty by nekde musely mit konec a treba by to zavedeni nakonec mozne bylo. 🤔

Nainstalujte DRMinfo a pošlete výsledek kontroly. https://play.google.com/store/apps/details?id=com.androidfung.drminfo&hl=cs&gl=US Pokud tam bude Widevine L3 nebo to je zařízení zcela bez Widevine, případně tam není rozumně vysoký HDCP level, tak je to problém s DRM (L3 je vyhovující na počítači, ale nevím, jak se VF TV na L3 tváří na Androidu). Pokud je to rootnuté zařízení nebo zařízení s odemčeným bootloaderem, může být problém v tom.