DiDiDi

Tak typický SOHO router, tj. ten, který má víc než jeden LAN port, má uvnitř switch - v principu úplně stejný jako samostatný switch. Když se správně nastaví a vše (včetně modemu) se zapojí přes LAN (nikoliv WAN) sloty, může i router fungovat jako klasický switch. Takže pokud se někomu někde válí starý nepoužívaný router, určitě si nemusí pořizovat switch (za předpokladu, že LAN porty podporují adekvátní rychlost). U některých routerů je i WAN port součástí interního hardwarového switche, jen oddělen od zbytku pomocí VLAN. V těchto případech pak jde i WAN port zkonvertovat na LAN a získat port navíc.

Záleží na routeru a jeho DHCP klientu. Já mám router s OpenWrt, který (pro IPv4) používá udhcpc/busybox. Tam stačí poslat signal, viz readme: Můj skript na výměnu IP: #!/bin/sh set -e if [ $# -ne 1 ]; then echo "specify (only) network device" >&2 exit 13 fi OLDIP=$(ip -br address show $1 | awk '{print $3}') echo "old IP address: ${OLDIP:-(none)}" PID=$(ps o pid,cmd -C 'udhcpc' | grep -Fe "-i $1 " | awk '{print $1}') kill -USR2 $PID echo "waiting 11 minutes after releasing DHCP lease" sleep 11m kill -USR1 $PID sleep 10s NEWIP=$(ip -br address show $1 | awk '{print $3}') if [ -z "$NEWIP" ]; then echo "failed to get new IP address" >&2 exit 14 fi echo "new IP address: $NEWIP" if [ "$OLDIP" = "$NEWIP" ]; then echo "received same IP address" >&2 fi A ano, stále to funguje, stále mám až tři veřejné (dynamické) IPv4 zároveň (na 4. WAN MAC adresu už se nedostane) - záleží (asi) na tarifu. Pro lidi s bridge + dynamickými IPv4 se zatím nic nezměnilo. Doufám, že to tak zůstane co nejdéle... 🙂

Nebo i v bridge bez změny MAC stačí opravdu 11 minut, ale MUSÍ se na starou adresu zaslat DHCP Release. Bez toho se musí čekat dlouho.

Pak stačí poslat DHCP Release, počkat >10 minut a požádat o novou DHCP lease (nebo prostě odpojit na víc než deset minut router/zařízení). Bez DHCP Release je třeba počkat o dost déle, nebo změnit MAC adresu WAN rozhraní routeru (ale bez restartu modemu to má svá úskalí).

@zajdee --- a/net/sched/sch_cake.c +++ b/net/sched/sch_cake.c @@ -2462,18 +2462,18 @@ static int cake_config_diffserv4(struct Qdisc *sch) /* class characteristics */ cake_set_rate(&q->tins[0], rate, mtu, us_to_ns(q->target), us_to_ns(q->interval)); - cake_set_rate(&q->tins[1], rate >> 4, mtu, + cake_set_rate(&q->tins[1], rate >> 6, mtu, us_to_ns(q->target), us_to_ns(q->interval)); - cake_set_rate(&q->tins[2], rate >> 1, mtu, + cake_set_rate(&q->tins[2], rate * 29 / 32, mtu, us_to_ns(q->target), us_to_ns(q->interval)); - cake_set_rate(&q->tins[3], rate >> 2, mtu, + cake_set_rate(&q->tins[3], rate >> 4, mtu, us_to_ns(q->target), us_to_ns(q->interval)); /* bandwidth-sharing weights */ q->tins[0].tin_quantum = quantum; - q->tins[1].tin_quantum = quantum >> 4; - q->tins[2].tin_quantum = quantum >> 1; - q->tins[3].tin_quantum = quantum >> 2; + q->tins[1].tin_quantum = quantum >> 6; + q->tins[2].tin_quantum = quantum * 29 / 32; + q->tins[3].tin_quantum = quantum >> 4; return 0; } @@ -2713,7 +2713,7 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt, q->rate_bps = 0; /* unlimited by default */ q->interval = 100000; /* 100ms default */ - q->target = 5000; /* 5ms: codel RFC argues + q->target = 10000; /* 5ms: codel RFC argues * for 5 to 10% of interval */ q->rate_flags |= CAKE_FLAG_SPLIT_GSO; -- 2.43.0 Nedělám žádné zásadní úpravy, jen měním poměry jednotlivých front tak, aby Voice měl 1/16, Video 29/32 a Bulk 1/64 celkového bandwidth uploadu - změna se projeví, jen pokud se použije diffserv4 (default je diffserv3, tj. jen 3 fronty, na tom tento patch nemění nic). Můj usecase je zejména streamování her přes Moonlight/Sunshine a PS Remote Play, proto to nafouknutí Video fronty. Taky jsem zdvojnásobil target, už si moc nepamatuji proč, tahle část možná není potřeba. Další část skládačky je samozřejmě správně prioritizovat packety pomocí DSCP - některé aplikace to umí přímo samy (např. VoWiFi na mém Samsungu se samo označuje a automaticky padá do Voice fronty, jak by mělo), jde to dělat na úrovni routeru ve firewallu/Xtables (např. podle použitých portů nebo IP) nebo i přímo na počítači (pak to lze vztáhnout na konkrétní aplikace) - např. u Woken viz https://learn.microsoft.com/en-us/powershell/module/netqos/new-netqospolicy?view=windowsserver2022-ps @r2d2S downloadem v principu vždy bude problém, protože nad tím, co přichází z internetu do routeru, nemáš jako klient téměř žádnou kontrolu. To nejlepší, co se dá dělat, je začít zahazovat konkétních flows, co překračují nějakou rychlost - u TCP to relativně spolehlivě zpomalí přenos, ale UDP se může dít všechno možné a co bude záviset na infrastruktuře VF a co/kdy ti VF pošle. Se shapováním downloadu jsem si tedy skoro nehrál. Jinak ale ano, jitter je problém i u mě, kabel se prostě s dobře udělanou optikou nedá srovnávat. Pingování defaultní brány (tj. nic blíž asi neexistuje): rtt min/avg/max/mdev = 5.522/7.413/14.094/1.529 ms Jinak pro OpenWrt jsou přímo připravené packages jako SQM a qos-scripts ( https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm a https://openwrt.org/docs/guide-user/network/traffic-shaping/traffic_shaping )

Já mám 50mbit upload (shapuju si pouze upload) a používám linuxový router (Turris Omnia s OpenWrt) s cake qdisc: K těm 52480 kbit jsem došel pečivou detekcí bufferbloatu (zahltil jsem pomocí traffic generatoru z jedné veřejné IP na druhou upload a následně se pingoval s vyšší DSCP prioritou - s bufferbloatem by latence postupně stoupala). Bufferbloat samotný JE na straně klienta řešitelný problém, je-li stabilní rychlost uploadu (což u kabelového VF je, aspoň u mě). Všechno ostatní, zejména jitter, ne. Download neshapuju, tj. zahlcení downloadu je možné, ale to se mi při poměru DL:UL 20:1 skoro neděje... S nějakou prioritizací (používám modifikaci cake, která mění poměr jednotlivých front voice/video/standard/bulk, bohužel cake je v tomto nekonfigurovatelný, tj. musím patchovat přímo linuxový kernel) packetů je pak v pohodě možné mít plně vytížený upload uploadem do cloudu / torrentem a u toho bez vlivu na latenci hrát hry.

Tohle (na obrázku) je úplně normální a relativně v pohodě (taky máš A). Pokud chceš něco lepšího, tak jedině vlastní router a QoS / traffic shaping.

Z některých míst teoreticky ano, ale u vyložených podvodníků bych nesázel, že to pomůže. Mnoho těchto zmrdů používá např. hack Facebooku z roku 2021, s tím nenaděláte nic (budou vám tvrdit, že číslo našli "náhodným generováním" atd.). Zkuste zadat číslo v +420xxxxxxxxx formátu na https://haveibeenpwned.com

Já bych si přinejhorším vystačil s jednou (ideálně dynamickou, pevná zrovna pro mě znamená víc nevýhod než výhod), ale tu jednu veřejnou IPv4 opravdu potřebuji - tedy dokud IPv6 nebude naprosto všude na světě (10-20 let). Mám starý tarif "gigabit za polovinu natrvalo" (Pevný internet Kabel 1000 Mbps s 50% slevou) a doteď mám opravdu konstantní úroveň služby (v dobrém i zlém, např. mám pořád jen 50mbps upload). Jestli mi VF prostě zruší všechny veřejné IPv4 a nezbude mi ani jedna, s tím, že si mám připlatit za tu jednu pevnou, tak ragequituji a budu Vodafone hanit všude kam půjdu. I kdybych měl smrdět na *DSL...

Jestli pro mě nasazení dual-stacku/IPv6 má znamenat ztrátu VŠECH veřejných IPv4 adres (teď mám 3 bez jakéhokoliv příplatku), tj. že mi nezbude ani jedna, tak si rád počkám. Třeba i 10 let...

Tak "opraveno"... Nejedná se o chybu, je tam upozornění, že to funguje jen do restartu. Já si tak aspoň všimnu, že se modem restartoval (což se děje typicky tak jednou za měsíc až dva). 🙂

Google IPv6 Statistics Takže dejme tomu nějakých 20 let?

Samsung, Google atd. s AI features v EU problém nemají...

Hlavní pointa šifrování DNS requestů/responsů je, aby je ISP neviděl...

HDCP přináší problémy, i když člověk má moderní GPU i monitor. Multimonitor nebo (nedejbože) multiGPU setup ve Woknech, Linux, adaptéry/splittery HDMI/DP atp. Můj monitor HDCP umí jen na některých vstupech (a ne v nejnovější verzi, což je u ne4k monitorů celkem normální, protože používají starší verze HDMI i DP, anžto nepotřebují bandwidth těch novějších). Taky MUSÍTE použít HW dekodér v GPU, se SW dekodérem to nefunguje.

? Kdyby byla možnost si pronajmout/koupit pouze DOCSIS 3.1 modem/bridge za menší prachy, tak to udělám, ale ta pokud vím u Vodafone není (naposledy DOCSIS 3.0 modem-only v dobách UPC).

Jestli mi seberou současné 3 veřejné (dynamické) IPv4, tak budu hodně mrzutý. Snad za to nabídnou aspoň full dual stack a stále aspoň tu jednu IPv4... A taky doufám, že se do té doby rozhoupe T-Mobile s IPv6 na mobilní síti. Pořád mi přijde vtipné, že kdybych měl v současnosti T-Mobile na mobilu i doma, tak se domů nepřipojím.

Jak to mám vědět? Já vidím jen mizerný (vzhledem k bitratu) výsledek. H264 při daných bitratech rozhodně může vypadat líp.

Pěkné, tj. kdyby to oboje bylo 1080p (což není, H264 je interlaced) a H264 enkodér použitý ČT nebyl takový paskvil (což bohužel je), tak by to při daných rozdílech v bitratech mohlo vypadat +- podobně kvalitně, možná kromě Sportu, kde HEVC s pouze o ~1,3 Mb/s nižším bitratem bude asi lepší každopádně. Za stávajících okolností (1080i + mizerné enkódování do H264) to bohužel vždy vyhraje HEVC (viz to staré vlákno). A samozřejmě platí, že se stejnými bitraty by HEVC bylo lepší ještě výrazně víc...

Úspornou patlaninou? 😄 H265 (za předpokladu použití rozumného enkodéru a rozumného nastavení) je za stejného bitratu vždy lepší než H264 (v podstatě s libovolným enkodérem). Jediná slabina H265 oproti H264 je výpočetní složitost a kompatibilita. A terestrální ČT mux je za všech okolností (během regionálního vysílání a mimo) vždy lepší obrazové kvality, než kabelový/satelitní, aspoň ČT Sport a ČT24, ale předpokládám, že i zbytek. Byť by ten rozdíl nemusel být takový, kdyby H264 verze používala nějaký lepší enkodér. Např. i ve srovnání s jinými H264 muxy je ten ČT horší.

V nějakém vlákně pár měsíců dozadu se toto řešilo. Kabel (VF) a satelit (Skylink) opravdu mají identický 1080i h264 mux/stream MIZERNÉ kvality - teď neřeším vysílání v době regionálního vysílání, ale běžné vysílání, které vypadá prostě špatně (artefakty, kostičkování) vzhledem ke kodeku a bitratu (h264 při daném bitratu rozhodně může a má vypadat o dost lépe). @Ondra - VodafonePokud tvrdíte, že toto 1080i h264 je LEPŠÍ obrazové kvality než 1080p h265, co je v terestrálním vysílání, tak jste se museli naprosto zbláznit. V pohybu (např. na sportovním kanálu) vypadá terestrální vysílání tak očividně a znatelně líp, že Vaši odpověď mám problém brát vážně... 😄 Během hokeje dokonce vypadal znatelně lépe ČT Sport ve vašem DVB-T bloku, což je reencode terestrálního vysílání do 1080i h264 s nižším bitratem než to co je v kabelu/satelitu. Tzn. váš h264 enkodér je zjevně o dost lepší, než ten ČT. Předpokládám, že reálný problém je ten, že z důvodů kompatibility nemůžete přejít na h265, takže prostě ten druhý lepší zdroj bez reenkódování použít nemůžete. Lepší ale opravdu není (kromě kompatibility)... Co se týče zvuku, ta 5.1 AC3 se mi zdá identická (bitrate atd.), takže předpokládám jde o tu stereo stopu (MPEG2 vs AAC, tuším).

??? Minimálně pro ČT Sport (během MS v hokeji) jsme toto na jiném vlákně řešili, terestrální verze byla o parník lepší. A taky to je (resp. aspoň během MS bylo) plnohodnotné 60p (ale např. při elektronické tužce ve studiu používali zjevně interlaced záznam). A i kdyby to bylo prokládané, H265 stream je MNOHEM kvalitnější, zejména kvůli tragické kvalitě H264 enkodéru, co ČT používá... Každopádně by mě (ještě jednou) zajímalo, s čím @Ondra - Vodafonesrovnává.

@CableGTo mě zajímá! Mám stále "gigabit napořád" 1000/50. Jak se "to ukázalo"? Měl jsem za to, že bych musel zvolit aktuální gigabitový tarif...

Vyšší než co? Terestrální/DVB-T2 H265 má rozhodně lepší kvalitu než satelit/kabel...

Nejde o žádný hack. Je to prostě nastavení chování ohledně ARP protokolu. Linux ve výchozím nastavení (arp_ignore=0) by měl bezproblémový přístup na web interface umožnit, jiné OS (popř. linuxová distra/routery, kde arp_ignore nastavili na jinou hodnotu) typicky ne. Tohle téma (přístup na web interface VFS) se tu již objevilo Xkrát (a ještě asi mnohokrát objeví), části lidí to vždycky funguje a části ne, podle mě právě proto, že různá zařízení (routery) jsou v tomto nastavená různě. Taky to může být o firewallu (nebo o fw a ARP zároveň), nemusí se líbit, když na WAN interface s IP z veřejného/internetového rozsahu přijde něco z 192.168.x.y... Je to určitě o firmwaru, v principu modem nemusí uchovávat nacachovaný ARP záznam připojeného zařízení, aby to fungovalo, Compal a další modemy tenhle problém neměly. Ale oba moje VFS, co jsem měl (jeden odešel), se chovaly takhle.