Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Michal Šmucr

Stran: [1] 2 3 ... 13
1
Sítě / Re:Router pro síť s UniFi za 1Gbps T-Fiber ISP
« kdy: 10. 12. 2024, 22:59:57 »
Správná cesta jak už tu někdo psal je oznámit jim SN vlastního ONU/ONT a oni to změní u nich, ale naklonování SN z jejich ONT je výrazně snazší a rychlejší a (zatím) funguje.

Aha, díky za vysvětlení.. do té specifikace jsem se díval, jen mě z toho nevyplynulo, že jsou ochotni tam povolit i jiné VID/SN. Takže by to teoreticky mohl dát i někdo, komu se nechce hrát s těmi SPF moduly.
A případně kouknout i třeba na seznam těch zařízení BBF.247
https://www.broadband-forum.org/testing-and-certification-programs/bbf-247-gpon-onu-certification
Tam jsou pak v seznamu i samostatné škatule třeba od ZTE, Sagemcom atp.

2
Sítě / Re:Router pro síť s UniFi za 1Gbps T-Fiber ISP
« kdy: 10. 12. 2024, 21:43:29 »
@dzavy @Hornik

Zajímavé info, pokud by se tazatel chtěl vydat touhle cestou. Díky.
Našel jsem ještě další info na https://hack-gpon.org/

Takže pokud by tohle někdo chtěl použít, tak jestli to chápu správně, musí nejdřív zjistit vendor id a sériové číslo z původního zařízení a pak to změnit ve flashce toho kompatibilního SFPčka, aby se to pro poskytovatele tvářilo identicky?
Protože T-Mobile nechce povolit jiné GPON ONT než ty své, co tam dodal? Což by u nich tedy vylučovalo použít cokoliv jiného než ty ONT, kde se dá potencionálně měnit VENDOR a S/N (ať už v jakékoliv formě - SFP, externí škatule).

I zas jestli mám být upřímný, pokud bych si to nevzal jako nějakou technickou výzvu, asi bych tam nechal tu krabici od poskytovatele přepnutou do bridge a šel dál. A pak si tam podle potřeby zapojil co chci.

3
Sítě / Re:Router pro síť s UniFi za 1Gbps T-Fiber ISP
« kdy: 10. 12. 2024, 17:04:11 »
A funguju tie krabice s Tmobile optikou?
Lebo toto vidim ako zakaldny problem a aj zakladnu otazku. Ak som pochopil spravne, tak Samuel1234 zhana hlavne router, ktory by vedel zapojit namiesto GPON routra od Tmobile.

Do libovolny krabice das jejich sfp. To by musel dat i do ty krabice od unifi.

Tak to úplně není, na zakončení GPON, XPON atp. potřebujete ONT (koncové zařízení), nestačí jen strčit SFP se správnou vlnovou délkou do nějakého routeru, nebo síťovky.

Osobně jsem s tím nikdy nelaboroval a tam, kde jsem se s tím setkal, tak bylo zařízení (Segacom, Huawei) od operátora, který to případně nastavil jak bylo potřeba (bridge, router) a bral jsem to dál víceméně jako blackbox, kde byla IP konektivita.
Nicméně při splnění daných technických podmínek operátora by se to mělo dát i vyměnit za jiné kompatibilní zařízení.
ONT boxy (často je to škatule, co má 1G PoE port a pak rovnou druhý opt. port) dělá třeba i TP Link, BDCom a není to úplně drahé.
Jsou tam standardy pro fyz. vrstvu, konkrétní varianty FEC, pak i třeba vzdálenou správu a upstream monitoring (OMCI).
Mimo to je tam i jedinečná identifikace každého konc. zařízení - vendor + seriové číslo. To může ta druhá strana oveřovat a jiné konkrétní zařízení bude nutné explicitně povolit.
Takže i s těchhle důvodů bych to spíš konzultoval s operátorem, případně pořád používal jejich dodané zařízení v bridgi.

Ubiquity také má různá koncová GPON zařízení, ale nikdy jsem je prakticky neviděl, a jestli jsem to správně pochopil, tak jsou primárně míněny na provoz, kdy beží zas jejich škatule na druhé straně. Tzn. někdo dělá komplet rozvod fiberu na jejich technologii, třeba někde v činžáku.

Každopádně to je řešitelné, pokud to někdo chce provozovat s dalším routerem/gatewayi.

4
Sítě / Re:Router pro síť s UniFi za 1Gbps T-Fiber ISP
« kdy: 10. 12. 2024, 14:28:58 »
No to je krasne a jaka je alternativa? Nc pro doamcnsoti a male az stredni firmy co by nestalo nesmysl, nebo bys neplatil licente za ruzne funkcionality ( Forty) neni...

Asi bych se nebál toho, že není alternativa. Záleží které funkcionality, případně výhody mají prioritu. Pokud někomu nesednou třeba jen gatewaye a firewally od UI, ale WiFi věci v pohodě, tak se to dá i realtivně v pohodě kombinovat. Třeba mít APčka od UI a ten malý Cloud Key controller (sw verzi běžící někde ve virtuálu) na jejich správu a pak k tomu přidat FW podle preferencí. Pokud někdo bude preferovat otevřenější řešení a půjde mu čistě o klasický firewall např. s nějakou základní VPN, tak může sáhnout třeba po něčem založeném na OpenWRT nebo pfSense. Mikrotik už jsem tu zmiňoval, když někomu vyhovuje ten ekosystém, tak tam je poměrně dost možností (mě by třeba nevadil FW, ale například jsem nechtěl jejich WiFi řešení, protože v té době jsem potřeboval bezproblémový fast roaming mezi APčky se všemi platformami, bez složitého nastavování a hledání problémů).
Jinak samozřejmě pokud bude někdo chtít jít nad rámec toho běžného filtrování a nebo třeba v budoucnu implementovat nějakou analýzu provozu na vyšších vrstvách (a nějaké návazné IPS, WAF atp.) spolu s nějakou podporou většího výrobce a nebo třeba sofistikovanější VPN klienty na různé platformy, co se připojují na tu GW, ověřují uživatele vůči AD atp. Tak ano asi dává smysl uvažovat i těch výrazně dražích řešeních od Forti, Checkpointu, Palo Alto atd.
Ale fakt podle mě záleží na konkrétním použití. Někdo je v pohodě, že si koupí komponenty, co spolu pak bude v různé míře integrovat.. Pro jiného zas může být velká výhoda, že koupí APčka, gateway, switche od jednoho vendora a pokud nebude mít nějaké specifické požadavky, tak to v podstatě nakliká z jednoho rozhraní, má od všeho notifikace, mobilní apky, hlídá mu to upstream liknky, má zálohy v cloudu, účty pro delegování víc správců.. atp., což přesně má UI.

5
Sítě / Re:Router pro síť s UniFi za 1Gbps T-Fiber ISP
« kdy: 10. 12. 2024, 12:32:45 »
Pročti si letmo jejich komunitní fórum a zjistíš, že bys ve skutečnosti nic takového nechtěl. Mj. veškeré jejich nové routery se ti vnuceně upgradují pod rukama a nelze tomu zamezit. V kombinaci s desítkami regresí v každém novém vydání čehokoliv, co vypustí, a absolutně neexistující QA, je to opravdu úžasné.

V jedné firmě používám asi dva roky Unify DM Pro a několik jejich APček s upstream prvkem od firemního Vodafone připojení (klasika routované veřejné IP). Cca čtyři vnitřní VLANy, tři WiFi sítě s nějakými prostupy a filtrací, plus je tam ještě downstream 48p Cisco CBS switch (to byla víceméně pragmatická volba, protože jsem to měl ozkoušené z jiných projektů a trochu jsem se bál, jak by Ubiquity switch nakládal s mulitcasty, IGMP snoopingem atp, což jsem nutně potřeboval pro určitá zařízení). Používám na gatewayi i L2TP VPN.
Taky jsem se toho trochu bál, přesně z důvodu toho, že tam se potencionálně zblázním z nějakých automagic věci. Ano občas tam pro mě bylo trochu komplikovanější něčeho docílit v porovnání s jinými FW, a ano občas bych bral trochu víc kontroly na pravidly.
Prošel jsem taky cca tucet aktualizací - minor i major včetně větších fíčur (podpora WG serveru, změny v logice firewall modulu, kdy zjednodušovali některé věci atp.). Ale zatím ťukám, žádná tragédie se nestala. Ty změněné/přidané funkce v aktualizacích nikdy nerozbily původní nastavení - vždycky tam byla možnost to předělat podle potřeba později.
O aktualizacích gatewaye případně modulů mě to vždycky poctivě notifikovalo, já jsem si zvolil, jestli a kdy to nainstaluji. Pokud jsem odložil nějakou z nich, nabídla se mi pak až další (např. nechtěl jsem instalovat první major verzi). Na AP mám nastavené aut. aktualizace, ale na gatewayi ne a zatím jsem se nesetkal s tím, že by to tuhle volbu nerespektovalo a něco se mi tam natlačilo automaticky.
Přes to všechno myslím, že není od věci si dopředu projít způsob, jak si manuálně zálohovat nastavení mimo UI cloud a třeba i nějaké možnosti manuální instalace firmware a modulů (deb balíčky) přes ssh.
Samozřejmě mám omezený rozsah zkušeností, zdaleka nepoužívám všechny funkce, moduly (třeba identity mgmt, kamery atp.), nemám tam IPv6 a zmiňuju jen jeden model té jejich GW, plus jsem poměrně konzervativní s nasazováním některých věcí.. Nevylučuju, že s tím někdo problémy nemá.
Ve hře byla i jiné varianta (např. Ubiquity WiFi, jejich kontroler a pak FW/gateway od Mikrotiku), ale tohle zatím šlape v pohodě.

6
Desktop / Re:GNOME sebere stisk klávesy
« kdy: 08. 12. 2024, 16:06:13 »
Sice ne přímo v Debianu, ale používám GNOME (od 3.32 přes novější 40-47) a graf. terminál (Gnome Terminal, Gnome Console - kgx) na víc různých distribucích, také s Waylandem a nikdy se mi popisovaná věc neděla.
Nemůže to být problém nějakého přizpůsobení, nebo rozšíření v Gnome Shellu, či použitého terminálu?
Zkusil bych si vytvořit nového uživatele, nechat všechno ve výchozím nastavení (žádný Classic nebo přidávání dalších rozšíření) a zkusit problém replikovat.
Případně to pak ještě zúžit a ověřit, jestli se to děje i s jinou aplikací pro terminál, např. Kitty, aby se rozlišilo, jestli je to záležitost Gnome Shellu.

7
Sítě / Re:Přepínání rychlosti routeru
« kdy: 06. 12. 2024, 23:50:04 »
Ani nevím jestli ten vypůjčený izolátor umožňoval PoE. Na přesný typ jsem odkaz nenašel a byl to 1Gbbs.
Máte pravdu u krabiček píšou dole v detailech že zádné napájení přes ne jít nemůže https://www.wimo.com/en/iso-plus  Ono je to těžké určit jak se těch 13.5 Mhz do kabelu dostává. Je to alchymie i když s dražšími měřáky to musí být zjistitelné. Uznávám že optika by byla určitě čistším řešením. Jsem spokojený za 2K hodně muziky mají děti:-)

Podle mě tam taky nemohlo procházet PoE, pokud v obou případech galvanicky odděluje a je to pasivní, tak to se nedá udělat moc jinak než trafem, přes které neprojde DC.
Akorát teď jak se ještě koukám na ten půjčený izolátor do DIN lišty, co jste posílal, tak ten je podle dokumentace stejně jen do 100Mbit. Takže by u něj třeba nemusely být zapojené všechny páry, příp. by tam mohla být i třeba menší šířka pásma (gigabit má 2x vyšší frekvenci). Takže by vám to stejně nepomohlo.

Já se s podobnými izolátory setkal jen jednou v nemocnici, ale koukal jsem na to jen ze zvědavosti, když jsem řešil něco jiného.. Když jsem se pak místního technika ptal, tak je to primárně kvůli tomu, že lékařská technika musí splňovat přísnější normy. A ta vestavěná trafa, co jsou v normálních ethernetových portech, tomu nevyhovují.

Nic, tak každopádně, ať vám to běhá :)

8
Sítě / Re:Přepínání rychlosti routeru
« kdy: 06. 12. 2024, 23:19:11 »
To me prijde jako mega blbost. Ethernet kabel neni z podstaty galvanicky spojeny se zarizenim, protoze v kazdem sitovem portu je oddelovaci trafo :D

Takze pomohlo ono zkraceni, nebo uprava vedeni trasy.

Tak hlavně, že to teď funguje po všech možných pokusech.

Ale přesně jak jsi zmiňoval, to mě napadlo taky. Vypadá, že je izolátor úplně pasivní, nejspíš tam taky trafo na každý pár. Nemohlo to třeba oproti tomu trafu, co je v Eth portu v routeru, pomoc třeba i s lepším CMRR?
Přičemž je pak zajímavé, že předtím p. Peterkovi nezabral stejně ten izolátor do DIN lišty, co posílal předtím. Tam taky nejspíš nebude nic jiného než zase trafo. Takže možná to bude teď kombinace konkrétního izolátoru, úprava vedení a těch feritů..?

9
Software / Re:Raspberry - systemové logy
« kdy: 06. 12. 2024, 11:43:49 »
No zkombinujete -p err s tím --since "24 hours ago", co psal P. Krčmář.
Ale samozřejmě bude záležet, jestli to co hledáte, bude mít tu správnou prioritu (-p) error, která odpovídá těm syslog levelům. Tohle pak záleží na programu, aplikaci, co ty záznamy vytváří.
Pokud je to ze systemd služby, tak to můžete dál zúžit třeba pomocí -u <nazev.service>
Případně pokud jsou to konrkétní komponenty (aplikace) tak za journalctl napíšete její cestu. Např. journalctl /usr/sbin/cron
Mrkněte se asi spíš na nějaký ucelenější přehled těch funkcí, třeba tady:
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

10
Software / Re:Komprimace do tar s datem a časem
« kdy: 06. 12. 2024, 11:02:48 »
Zkuste vyhodit ty jednoduché úvozovky okolo formátovacího řetězce pro date a pak před každé procento přidat zpětné lomítko, abyste to odescapoval.

Ale tohle je přesně ten opruz, který může vést i k nečekaným výsledkům (vezměte si, že třeba děláte nějaký mazací one-liner, co se bude pokaždé chovat jinak, podle toho jestli se spustí z cronu, nebo interktivního shellu - to může dopadnou i pěkným průšvihem). Proto je podle mě lepší ten sh skript.

11
Software / Re:komprimace do tar s datem a časem
« kdy: 06. 12. 2024, 10:50:26 »
Není úplně dobrý nápad používat tyhle shell věci a spec. znaky přímo v crontabu. Podle konkrétního démona cron a zvoleného shellu (nastavení SHELL= v crontab) můžete narazit na problémy se zápisem těch procent, co se pak musí escapovat, těch stejně tak těch apostrofů, případně vnořených úvozovek. Většinou to jde přepsat i do té jednořádkové podoby, aby to crond sežral, ale je lepší se tomu vyhnout.

Udělal bych si nějaký shell skript např. (/usr/local/bin/documents-backup.sh), u kterého bych si odladil funkčnost, a pak mu přidal záznam v crontabu, kde by bylo už jen např. /bin/bash /usr/local/bin/documents-backup.sh

Jinak jestli budete to budete mít napsané jako skript, můžete se pak mrknout i na použití systemd timerů místo cronu na spouštění.

https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html
https://wiki.archlinux.org/title/Systemd/Timers

Na moderních distribucích je tohle většinou lepší varianta s víc možnostmi, byť musíte typicky pro každý timer udělat dva soubory.

12
Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu
« kdy: 06. 12. 2024, 09:14:18 »
Problém s IPv6 (na DSL cetinu) jsem také měl jakmile vyšla verze firmware 7.16 takže jsem se vrátil na 7.15.3 jelikož nebyl čas to řešit a problém zmizel.

Teď už myslím verze 7.16.2 takže zkuste nejdříve na nejnovější a pokud ne zvažte downgrade.

Nemyslím si, že by to byl ten primární problém, o kterém píše. Jak pak vyplynulo z další diskuze, tak je to spíš věcí konfigurace (správná velikost MTU v PPPoE klientovi, případně její posílání v ND (RA) nebo přidání pravidla pro MSS clamping). Viz můj dlouhý post výše. Nesouvisí to až tak s případným bugem, pokud to není dobře nastaveno.

Mikrotik, který jsem používal na testy, měl firmware s RouterOS 7.13 tuším někdy z loňska.
Teď po testech jsem to aktualizoval 7.16.2, chovalo se to úplně stejně.


13
Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu
« kdy: 06. 12. 2024, 01:10:12 »
O.K. tak si sám napíšu update.
Vrtalo mi to hlavou a ozkoušel jsem si to na Mikrotiku s VDSL modemem v bridge režimu (O2, Cetin).
PPPoE klient nastavený na MTU 1492, to chodilo podle předpokladu dobře.

Vyzkoušel jsem si všechny zmíněné scénáře

- Nenastavovat nic dál, nechat to na dynamické zjišťování PMTU až ke klientovi
ICMPv6 je ve výchozím nastavení RouterOS povolené, zpráva packet too big (PTB) prochází na stanice.
První spojení se nenaváže, ale vytvoří se záznam v lokální routovací tabulce s menším MTU pro hosta venku (server). Dá se v Linuxu ověřit přes ip -6 route show cache. Další spojení pak proběhne v pohodě s použitím nové MTU.

Horší pak je, jak se tohle chování projeví se standardními aplikacemi. Chrome i FF dlouho čeká na timeout s chybou, nebo se musí načítání stránky přerušit a refreshnout. Druhé spojení pak načte základní stránku, ale pak se typicky čeká znovu (další servery s reklamou, skripty, diskuzí atp.), takže zas přerušit a dát refresh. Totéž pak třeba telefon s iOSem. Prakticky nepoužitelné.

To btw. vysvětluje i to zdánlivě divné chování, co popisoval tazatel. Není to tak, že by to chodilo v konkrétním browseru a jiném ne. Pokud to zkouší nejprve v jedné aplikaci, tak se to nenačte, ale udělá se PMTU záznam a v druhé, co zkouší později, už to pak po dobu jeho platnosti záznamu chodí.

- MSS clamping
Na RouterOS jsem to naklikal v GUI pro mangle tabulku a forward chain. Případně přes konzoli něco jako:
Kód: [Vybrat]
/ipv6 firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes
protocol=tcp tcp-flags=syn

Tohle zafunguje vcelku spolehlivě a vyřeší problémy s načítáním většiny stránek.
Nevýhoda je, že to logicky funguje jen na TCP spojení. UDP spojení to neřeší, nemají MSS field.
Takže by se muselo spoléhat na to, že ty aplikace, co UDP používají, si vyřeší reconnect po zjištění PMTU (viz předchozí způsob). Nevím například, jak to je s aktuálním použitím QUIC/HTTP3, co běží přes UDP, jaké mají servery MTU, a jestli je dobré na tenhle workaround spoléhat do budoucna.

- snížení inzerovaného MTU v RA (ND) na 1492
To samozřejmě řeší komunikaci všemi protokoly, aby to prošlo přes WAN síť, a funguje spolehlivě. Nevýhoda už tu byla předtím zmíněná, pokud spolu klienti komunikují v LAN mezi sebou po IPv6, používají také menší MTU.
Otázka je, jak velký je tohle prakticky problém.. za mě je to pořád preferovaná varianta, jak to řešit pro většinu menších sítí.

Takže - pick your poison. A víceméně mi to odpovídá na otázku, proč třeba někteří výrobci SOHO routerů/modemů, které jsem viděl, měli ve výchozím nastavení všechno naráz - bylo povolené ICMPv6, MSS clamping a ještě k tomu replikovali MTU od upstream linky v RA.

14
Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu
« kdy: 05. 12. 2024, 14:10:14 »
Podle mě to tak být nemá. Jakým MTU pak komunikuje takový klient po lokální síti (přes switch)? MTU má mít klient na 1500, pokud komunikuje skrz něco, co má menší MTU, tak se mají fragmentovat. Ne že má mít klient za každých okolností MTU nejmenší, které má zařízení, které je po cestě v komunikaci.

Beru, to je moje blbá a příliš kategorická formulace v tomhle kontextu. Teoreticky máte samozřejmě pravdu a není to optimální přesně z důvodů, co jste popisoval. Na stranu druhou, pokud tazatel opravdu neblokuje ICMP6, mělo by tedy fungovat PMTUD, a přesto se mu něco ztrácí a má problémy s připojením, tak by to bylo první, co bych za dané situace zkusil. A mít na PPPoE klientu MTU 1480 a v RA pak 1492 nedává smysl. Buď tedy nechat RA na 1500 a zkoumat proč přesně nechodí v konkrétních spojeních PMTUD, nebo srovnat to inzerované MTU s upstream spojením, případně ještě zkusit MSS clamping (v iptables je to clamp-mss-to-pmtu, neznám přesně syntaxi téhož v RouterOS), jak je i zmíněno v linkovaném článku od p. Caletky.

Já jsem primárně vycházel z toho, že většina "běžných" modem/routerů (jak přímo od providerů, tak koupené ve volném prodeji), co jsem viděl na XDSL linkách od Cetinu, prostě v tom RA inzeruje MTU z WAN rozhraní, případně je tam pak i rovnou zapnutý ten zmíněný clamping (to je třeba případ ASUSWRT), přestože je zároveň průchozí ICMP6 a ty PTB pakety. Jestli to dělají jen pro sichr a nemuselo by to být, nebo tím třeba obcházejí potíže u některých specifických klientů (op. systémů), je věc druhá.

Nevím, jak daleko je s problémem tazatel, nějak se už neozval, pokud to úplně nevzdal.
Můj troubleshooting by šel tak, že bych si na úvod potvrdil, že to souvisí s MTU a není to jiný problém, třeba tím, že na test sundám MTU na lokální síťovce v počítači - klidně i třeba na 1400. Pokud by se mi pak stránky načítaly, vrátil bych to zpět a řešil až návazně jak to udělat dál, donastavit ten router, monitorovat ICMP6, ozkoušet i ostatní klienty (telefony, televize atp.).

15
Software / Re:FFmpeg a výroba náhledů v AVIF
« kdy: 04. 12. 2024, 09:45:52 »
Tahle zpráva je omyl, pardon :)

Stran: [1] 2 3 ... 13