DiDiDi

Co tak koukám, tak např. naši severouhorskí bratia mají běžně asymetrii i na optice, tj. mít symetrický up/download rozhodně není samozřejmost, i když to z hlediska koncové infrastruktury jde. U DOCSISu (kterékoliv verze) je upload problematický vždy a o symetrii si můžeme nechat zdát, zejména když se kvůli legacy DVB-C televizi koaxiální kabeláž nevyužívá 100% na internet.

250 + 100

Bum! A najednou mám 100Mbit upload a navíc platím o 200 Kč měsíčně míň. Tzv. retenční kouzlení. 😄 Měl jsem to udělat už před rokem... Jen mi teda paní z retenčního volala V NEDĚLI PŘED OSMOU RÁNO (WTF?😴). To bolelo, ale stálo to za to.

https://www.epravo.cz/top/clanky/vecna-bremena-v-oblasti-telekomunikaci-117459.html

Já tam volal a nabídli mi zvýšení uploadu za... 150 Kč měsíčně navíc. Navíc jsem zjistil, že mi účtují 100 Kč za pronájem Vodafone Station, který nepodporuje Wifi 6.

Jo takhle! Tak to je pak jiná! Pak v podstatě TM dělá to, po čem se tu kdysi volalo (možná ve vlákně "Vlastní modem"?) - možnost hloupého modem-only zařízení za nižší cenu než standardní modem+wifi+router. Jen je to v této podobě bez nutnosti podporovat / řešit kompatibilitu více zařízení. To je hodně zajímavé, zajímalo by mě, co je k tomu vede, PR si na této velmi skryté slevě pro pokročilejší uživatele s vlastním routerem asi nenahrabou...

Bridge je jenom režim/nastavení modemu (resp. modemo-wifi-routeru - čisté modemy VF ani TM nenabízí, kdysi je pronajímalo/prodávalo UPC a ty v principu nic jiného než bridge dělat ani nemohly), které vypne funkcionalitu routeru/wifi a nechá jen základní funkcionalitu kabelového modemu - s tím, že router zákazník použije vlastní. Tak ještě aby si ISP za vypnutí části/funkcionality pronajímaného zařízení chtěl účtovat prachy... To bych je hnal! 😄

No ještě aby se za režim bridge připlácelo... 😄 To nedělá snad žádný ISP.

Bez poplatku za modem? Za pronájem modemu se platí 70 Kč měsíčně...

To s tím IPv6 u VF není pravda, kdybych chtěl vyměnit 3 veřejné dynamické IPv4, co teď mám, za IPv6, tak můžu. Naopak jsem při zřízení služby měl IPv6 by default (tehdy přes DS-lite) a o IPv4 musel žádat.

Takže v podstatě úplně přesně to samé, co u Vodafone, mínus (bezplatná) možnost dynamických IPv4-only. Na houby.

Zrovna tohle bylo při tom brněnském výpadku k ničemu, protože dali ten banner (co jsem citoval ve svém předchozím příspěvku) POUZE na /vypadky, ale když jsem vyplnil adresu, tak banner zmizel a bylo tam jen klasické "Ve vaší lokalitě neevidujeme žádný výpadek služeb." 😄 Jinak co si pamatuju nějaký výpadek v minulosti, tak Vodafone (nebo to bylo ještě UPC?) uměl při volání na infolinku na výpadky upozornit, než přepojil na operátora. Je rozhodně fakt, že tohle fórum by nemělo být hlavní (a už vůbec ne jediný) zdroj informací o výpadku.

Už tam Vodafone na výpadcích něco (málo) má:

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.

Bez příplatku za pevnou je pouze neveřejná IPv4 adresa, nebo aspoň jedna dynamická veřejná?

Tak stále jde o Vodafone infrastrukturu (a službu v principu extrémně podobnou Vodafone kabelovému internetu). A je to v offtopic kategorii... Tak to tu prostě ignorujte... 🙂

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...