Ondrej1

Rychlý test - půčit si někde (hloupý) switch a dát ho mezi Vodafone Station a tiskárnu. Už tady totiž byly reportovány problémy Vodafone Station s některými Mikrotiky, tohle vypadá podobně.

U mě v práci v pořádku, uptime 160 dní (Compal v bridgi).

@zajdeeDíky, snažil jsem se o tom najít dovědět víc, ale zatím je to syrové a nikdo nic nevěděl, za zímku stojí perlička z ceníku: V ceně tarifu Cable Internet 250–1000 je přidělení jedné privátní IPv6 adresy. Tak aspoň vím, že se nejedná o chybu a nemusím dál pátrat.

U Compalu normálně funguje http://192.168.100.1, nesmí se dát https.

@sodekcz Díky za zprávu, jakkoli nepotěšující. Pochopil jsem to dobře, že pokud jsou VF a Mikrotik připojeny přes (hloupý) switch, tak k problému nedochází? (Chci teď v práci upgradovat dvojici µTiků právě za RB5009, ak ať vím, co mám čekat).

Zkusil jsem si to a na Mikrotik mi paket na port 21 normálně přijde (tedy ze sítě Vodafone), SYN pakety se v logu ukážou, čili určitě to není řezáno globálně (@tomus). Tak přijde i ze sítě O2, čili Vodafone je v tom (skoro jistě) nevinně. (Jinak testoval jsem to tak, že na (skoro) začátek input chainu ve firewallu jem dal logovat a zahodit tcp pakety na port 21) Ještě nápad – neběží na tom Mikrotiku náhodou ftp služba na portu 21? Pak by se to mohlo chovat takhle. Já ji mám vypnutou:

V podstatě vyšuměl z několika důvodů: Puma 6 bug je poměrně specifický (velké množství otevíraných TCP spojení) a jenom (nepatrná) menšina těch, kdo má problém s Vodafone/DOCSIS internetem ho má způsobený tímhle bugem (ale jsou takoví, ne že ne). Ti, kdo s tímto bugem bojovali, měli ještě dost dalších důvodů, proč je Vodafone/DOCSIS internet špatně a s rozvojem optiky utekli na optiku. A jak známo, kde není člověk, není ani problém. S možností mít Vodafone Station (VS) k nižším tarifům a s možností přepnout VS do bridge se problém stal řešitelný pro všechny, kdo jsou Puma 6 bugem postižení, a to za kulantních 30 korun měsíčně. (VS obsahuje Puma 7 chipset, který tenhle problém nemá.)

V práci mám na Compalu uptime 127 dní, doma to bude dost podobné, v obou případech shozené do bridge. Ve srovnání s předchozím Ubee mě štve spotřeba elektřiny, ale jinak spokojenost.

Tady je to jednodušší, na WAN (nebo ether1 nebo patřičném) rozhraní Mikrotiku nechat DHCP klienta a o víc se o IP adresu nestarat.

Firemní i domácí odpovídají (compal v bridgi, za ním různé Mikrotiky). Zkoušeno vzájemně na sebe, čili v síti Vodafonu jenom přes pár hopů, odpoledne to zkusím odněkud hodně zvenku.

Taky po mnoha letech nová IP.

Speedtest na brněnský Vodafone naměří správně 500/50.

RB4011 je bezpochyby nádherný kousek hardwaru, ale pokud jde jenom o to uroutovat 1Gbit, tak by to ze stáje Mikrotiku měly dávat i RBD52G (hAP ac2) a pokud není potřeba wifi, tak RB750Gr3 (hEX). Oba mi tu routují 500 Mb a dávají to s obrovskou rezervou.

Díky za zprávu, závěr je celkem jasný, pro tenhle use case je Vodafone nepoužitelný. Přiznám se, že já osobně, kdybych měl možnost optiky, tak o DOCSISu vůbec neuvažuji. Tož všecko nélepší s tem pertinaxem.

K původnímu dotazu - určitě není pravda, že to dělají všechny routery/oblasti. Za zbridgeovaným Compalem mám Mikrotik a ten restartuji při jeho každém updatu (minimálně jednou měsíčně) a už několik let se mi IP adresa nezměnila. Ohledně důvodu častých restartů routeru, sice dobře rozumím důvodu tohoto počínání, ale podle mě je to Špatné Řešení. Pokud mám spolehlivý router a spojení vyhnije na straně klienta (v případě IoT téměř jistota), je lepší restartovat jenom to(ta) rozhraní routeru, kde jsou IoTy připojeny a nikoli celý router. Navíc z hlediska (ne)bezpečnosti se stejně doporučuje mít IoT na jednom virtuálním rozhraní a pak je ten restart ještě jednodušší.

Taky mi to volalo, velice špatná angličtina v nějakém call centru, buď podvod, nebo nesmysl. Položit, neřešit.

Sekundového zpoždění u 3-way handshaku při otevírání TCP spojení si ve škole nemá nikdo šanci všimnout. Byl jsem první, kdo na ispforu navrhnul PUMA 6 bug, ale nejsem si tím moc jistý. Zaprvé, to zdržení se projevuje pouze u 3 way handshaku při otevírání TCP spojení (a všechno ostatní je s určitostí nezpožděné), nebo může být i jinde (jenom ho tam nepozorujeme)? V tom prvním případě to totiž na PUMA 6 bug moc nevypadá (v tom druhém ano). Asi by bylo nejlepší nechat všechno (mikrotik, konfiguraci, servery) tak jak je a zkusit to na záložním (neDOCSIS) připojení, optimálně ADSL (a nejlépe od Vodafonu 😀). Pokud problémy vymizí, je to jasné. Při tomhle scénáři (600 spojení) může být až příliš mnoho chyb na příliš mnoha místech. Já jsem to včera otestoval u nás (bílý Compal v bridgi, za ním RouterBOARD 750G r2) dostal jsem se na 700 spojení (většina TCP, něco málo UDP, dle Mikrotiku) a problémy jsem nepozoroval. Každopádně výsledek mě moc zajímá. A pro úplnost dodám odkaz na PUMA 6 bug test: http://www.dslreports.com/tools/puma6 (u nás to máme červené jak muletu, ale nikomu to nevadí.)

Pokud to se starým notebookem fungovalo bez problémů (i na 5 GHz ?) na současném notebooku to bezproblémově funguje po kabelu, tak to poměrně jednoznačně ukazuje na problémový ovladač wifi na novém notebooku. Začal bych tím, že bych popátral po nejnovějším/spolehlivém ovladači, pokračoval pátráním v logu (win11, router i synology) jestli to nedá hint co se děje.

Na firemním účtu mi to dává termín začátek ledna, u domácího mi to píše Změna termínu - převedení vámi využívaných služeb do systému Vodafonu proběhne v jiném termínu. Dáme vám vědět hned, jakmile ho přeplánujeme.

Ještě ke včerejšímu výpadku Facebooku a spol - indukovaně exUPC. Celé odpoledne a večer jsem pracoval jsa připojen přes exUPC a bez jediného zakoktání. Je fakt, že používám Google DNS 8.8.8.8. Vypadá to že: Nasadili jsme náhradní řešení, všechny části naší pevné sítě jsou navzdory přetrvávajícímu masivnímu výpadku Facebooku plně funkční. (z Twitteru Vodafonu) se týká jen přetíženého DNS serveru exUPC. Jednou bylo zase lepší mít googlovský DNS, tak to příště bude naopak 😀.

Jak psali přede mnou, IP adresu vždy dostat přes DHCP, nikdy nenastavovat ručně. Když jsem před pár lety měnil router, tak stačil jeden telefonát na infolinku/techniky, kde jsem jim nadiktoval novou MAC adresu (oni ji navíc viděli, že ano, tak jsme ji jen zverifikovali) a nastavili ji jako novou kanonickou. Klonování MAC adresy bych bral až jako úplně poslední možnost, pokud selže všechno.

U business adres to nefungovalo nikdy, ani za UPC. Teď jsem cvičně zkusil svoji adresu v několika databázích a dostal jsem Prahu (nejčastěji), Plzeň a Ostravu, přičemž jsem ve Zlíně. S tím ale nemá Vodafone (UPC) zas tak moc do činění, to je iniciativa těch společností poskytujících geolokační informace, a zatímco u home přípojek dělají s většími adresními bloky, tak u business jsou buď malinkaté bloky (nebo dokonce jednotlivé adresy ?) a nestojí jim to za tu drbačku. Jak píše @Adolf.Shitler, vzít na vědomí a neřešit. Nebo vyřešit jinak (u mapy.cz zapamatovanou pozicí, nebo linkem, nebo vyhledáváním).

V evidencích je nepořádek odedávna. Měl jsem podobnou situaci před 10+ lety ještě za časů Karnevalu, tam to ale bylo naopak. Ve sklepě mi trčely ze zdi dva zelené koaxiály, ale Karneval tvrdil, že máme doma nainstalované zásuvky. Natěstí se nechali přesvědčit, poslali technika a ten zřídil zásuvku a od té doby pohoda. Využil buch nabídku @Marek-26 a řešil to s ním, má asi nejlepší přístupy do systémů a k technikům, ale souhlas s @tomus, že to vypadá nadějně.

Den je moc, teď jsem něco připisoval do tématu Veřejná IP po 18 hodinách, příspěvky to spojilo a moc smysl to nedává, chtělo by to fakt jak chce @tomus, příspěvek označit nepřečtený a spojovat je jen v řádu několika málo hodin.

Před chvilkou objednáno, slečna na infolince se dušovala, že se nic nezmění. Každopádně do 24 hodin dám vědět, jak to dopadlo. @tomus a @Marek-26 zatím díky. Nedočkavě jsem ráno restartoval modem, výsledek je 500/30 a ip adresa je veřejná, a to dokonce (poměrně logicky) ta původní. (Dynamická, co se už dva roky nezměnila).