Příspěvky

1

Sítě / Re:Nefunkčné niektore webstránky

« kdy: 02. 10. 2025, 17:03:14 »

Občas jsem někde zažíval podobně divné problémy s připojováním, když nebyl nastavený MSS clamping.
https://support.ispsupplies.com/portal/en/kb/articles/pmtu-and-mss-discovery-issues-resolved-with-mikrotik
Ten bývá v dost domácích zařízeních nastavený rovnou.

Např. pro PPPoE je to 1492 - 40 (TCP+IP headery) = 1452, tzn. u všech SYN paketů s MSS > 1452 se to nastavuje na 1452.

/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=pppoe-interface tcp-mss=1453-65535 log=no log-prefix=""

(pak upravit pppoe-interface podle vašeho, podobně pak u ipv6, jestli používáte)

Možná už to takhle máte nastavené, nebo to nezabere, ale jen, že je mi fakt divné, že by se na dva konkrétní servery náhodně nedalo připojit podle verzí ROSu.

2

Sítě / Re:Výběr vhodného AP namísto Unifi U6 Pro

« kdy: 02. 10. 2025, 01:06:00 »

Uplink do baráku je 2Gbps symetricky přes optiku, optika je i mezi switchi, do místností roztaháno v metalice cat6. U6 Pro je ve dřevěném stole, takže tam by rušení být nemělo. Když ze switche kam je připojené připojím kabel, dostanu tam v pohodě 1Gbps rychlost.

Zajímavé ale je že když si tam připojím notebook (wifi 6) a jsem na tom AP jediný client, nedostanu z něj víc jak 200 / 200 Mbps UL/DL.

Mám také někde dvě U6-Pro, běžně tam dostávám z notebooku přes 500M (např. při kopírování do NASu). Na 5GHz a AP jsou klasicky v podhledech.
Ale záleží to samozřejmě i na konkrétním zařízení - jak široké kanály podporuje, kolik souběžných streamů použije při MIMO (typ. 2x2), jaké má antény. Tohle všechno by mělo být vidět v UI kontroléru (tzn. v Cloudkey u vás), bývají tam i historie s výkonem signálu a režimy pro každé zařízení, co se tam připojí.. takže se případné problémy dají dohledat i ex post.

Tzn. nablízko mi těch 200Mbit přijde skoro málo, pokud to využívá MIMO a není tam nějaká jiná potíž. Můžete s tím AP zkusit třeba manipulovat, třeba ho vytáhnout a položit vyloženě na stůl logem nahoru?
Jinak na tyhle testy je obecně asi ideální spustit si někde v lokální síti iperf, abyste u těch vyšších rychlostí vyloučil případné variace na běžných veřejných speedtestech v internetu.

3

Sítě / Re:Výběr vhodného AP namísto Unifi U6 Pro

« kdy: 01. 10. 2025, 23:26:00 »

Pokud tam není jiný problém (třeba zmíněný saturovaný uplink), tak mi další stejné AP také přijde jako nejrozumnější další krok na vyzkoušení, zvlášť jestli máte ještě CloudKey, co je může obě řídit.
Nicméně asi to bude stejně na trochu laborování - najít nějaké rozumné fyzické umístění na opačné strany místnosti a orientaci tak, aby v ideálním případě byly rovnoměrně rozložení klienti na obě AP.
Pak s tím taky nejspíš poladit nastavení - samozřejmě pro každé AP různé kanály v preferovaném 5GHz pásmu, možná na každém snížit výkon a nastavit nějaké vhodné minimální RSSI, aby se na AP nepřipojovaly ty vzdálenější klienty a asociovaly se s tím druhým, pokud u něj budou blíž. To je opravdu o zkoušení v konkrétních podmínkách - jeden extrém je, že budou všichni viset na prvním AP a na druhém nebude nikdo. Druhý extrém je, že budou pořád přeskakovat z jednoho na druhé, což je samozřejmě taky špatně.
Tohle víceméně platí pro všechny podobné systémy.

4

Hardware / Re:Rozdílné barvy na monitorech Dell a Mac

« kdy: 29. 09. 2025, 10:05:25 »

Jinak jestli je to to, co si myslím, tak by to mělo být pěkně vidět na standardních testech na Lagom.
http://www.lagom.nl/lcd-test/
Specificky - Black Level, White Saturation.

Jinak tady třeba pán řeší to samé s Dell monitorem..
https://www.mathewinkson.com/2013/03/force-rgb-mode-in-mac-os-x-to-fix-the-picture-quality-of-an-external-monitor/
Je to starý post, netuším co z toho bude pořád funkční přes 10 verzí macOSu.

5

Hardware / Re:Rozdílné barvy na monitorech Dell a Mac

« kdy: 29. 09. 2025, 09:55:54 »

Pokud tu barvy dokážete zapsat pomocí 8bitových RGB složek, tak ji 8-bitový monitor vždy nějak zobrazí (na místě kde má být, nějaká barva bude).
Vás předpokládám trápí, že v PC režimu ta barva vypadá jinak, než je vaše představa získaná z Mac monitoru.
Obávám se, že takhle od stolu nelze určit které zobrazení té RGB definice barvy je objektivně správnější, pokud není daný monitor zkalibrovaný s pomocí nějakého vzorníku.

Úplně si nemyslím, že tam dochází k nějakému lehkému barevnému posuvu nebo drobné změně podání, co by řešila kalibrace atp.
Tohle vypálení světlých barev (clipping) většinou nastane následujícím způsobem.
Počítač, ať už z jakéhokoliv důvodu, posílá signál jako YCbCr (rozdílové složky) s plným rozsahem (0-255). Monitor pak sice tenhle režim umí (protože je kompatibilní s video zdroji přes HDMI), ale počítá s rozsahem omezeným (16-235), který pak aplikuje při konverzi na nativní RGB pro zobrazení na panelu. To pak způsobí zmíněný clipping (jak u černé, tak u bílé), obrázek je pak také i nepřirozeně kontrastní.
Tím, že změní gamma křivku na 1.8 (která je také součástí té konverze), tak to celé ve středech ztmavne, ale zároveň to trochu ovlivní i ty nejsvětlejší barvy tak, že se to úplně neořeže.

To je můj odhad, ale samozřejmě může tam být i spousta jiných věcí (rozhašené nastavení monitoru, experimenty s ICC profily na Macu v Color Syncu atp.).
Ale jak jsem psal, nejčastější je to u specifických monitorů a toho jestli se správně pošle EDID (podle kterého počítač volí ty režimy), případně jak se interpetuje. U počítaču s Windows se tohle dá dost často jednoduše přebít v nastavení grafické karty (NVIDIA, AMD).
Na Mac existovaly různé i komerční tooly, např. BetterDisplay, co tohle uměly také pomocí modifikace EDIDu. Ale dlouho jsem to nepoužíval, netuším, jestli to chodí i na Apple Silicon Macech a nových systémech.. bývaly s tím i trochu opruzy, protože se ty změny aplikovaly až po přihlášení a natažení utility atp.
Jak jsem zmiňoval, má smysl otestovat i DisplayPort, kolikrát se to přes něj chytne nativně v RGB.

6

Hardware / Re:Rozdílné barvy na monitorech Dell a Mac

« kdy: 29. 09. 2025, 01:31:09 »

To bude nějaká ptákovina v tomhle konkrétním případě.

To nastavení MAC/PC přepíná gamma křivku (gradaci z černé do bílé) mezi 1.8 a 2.2.
Všechny novější Macy (asi 15-20 let) používají stejný standard jako PC, tzn. sRGB prostor a 2.2 gammu, protože to byl strašný opruz pořád řešit u monitorů na obě platformy.
To že vidíte nějakou světle růžovou, jen když to přepnete do (legacy) Mac režimu, mi přijde spíš workaround, který rozhodí i ostatní barvy, než řešení původního problému.
Monitor by měl být i v PC módu a tyhle barvy normálně zobrazit (stejně jako na Windows). To, co ovšem občas nastává je, že se při používání různých adaptérů a HDMI někdy do počítače (ať už je to Mac nebo PC) nepřenese korektně EDID, a počítač si pak třeba myslí, že displej je televize s omezeným rozsahem nebo místo RGB používá YPbPr režim s rozdílovými složkami. Při konverzích barevných prostorů, pak může nastat třeba clipping, kdy to tyhle světlé barvy zobrazí jako stoprocentní bílou.

Mrkněte se na macu do Utility > System Information.. V něm je pak sekce Graphics/Displays. Tam by vám to mělo ukázat víc o aktuálním režimu.
Pokud tam narazíte na problém, možná bych zkusil jiný adaptér USB-C na HDMI, nebo ještě líp kabel USB-C DisplayPort např. https://www.krup.cz/default.asp?cls=stoitem&stiid=5555
Většinou to s DP těmihle problémy netrpí.
Také pokud jste to zkoušel ještě poladit, abyste viděl barvičku, před porovnáváním bych na monitoru ještě preventivně resetoval nastavení.

7

Windows a jiné systémy / Re:Digitální licence Windows 11 a přesun do KVM

« kdy: 20. 09. 2025, 12:46:11 »

Řešil jste to v případě Windows 10 nebo Windows 11? To omezení bývalo u starších verzí Windows, ale Windows 10 už bylo možné i v OEM verzi instalovat do virtuálu. Řešilo se to třeba zde: https://forum.root.cz/index.php?topic=24342.15

Řešil jsem to vícekrát primárně pro Windows 10 (s tím, že 11 jsou víceméně to samé). Dotazy na MS partnery, případně na compliance oddělení ve firmě (a počítám následný dotaz na MS). Výsledek tehdy byl, že v pořádku pro tohle použití (lokální hypervizor na strojích vývojářů a administrátorů) je plná retailová nebo firemní volume licence.
Totéž pak od Parallels, jestli nemají nějaký OEM deal s MS.. "Ne. Kupte si za 200 USD licenci na Online MS Store".

Je tam samozřejmě pořád nějaká možnost, že mohli být papežštější než papež.. nebo partneři chtěli prodat dražší licence, ale úplně bych na to při auditu nesázel

Tu pasáž z OEM EULA (nenašel jsem už teď v rychlosti Windows 10, ale 11 je obdobné) ohledně provozu (dedikované) OEM licence ve VM znám.. A interpretovali mi to tak, že je to pro primárně pro vendory těch virtualizací nebo dodavatelé systémů, kteří za určitých podmínek můžou udělat pre-deploy OEM klíčů a navázat je na nějaké identifikátory podobně jako to dělají třeba výrobci počítačů (HP, Dell, Asus). Ale tohle mám zprostředkovaně.

Každopádně to, na co se ptal Darebáček, mi přijde jako trochu jiná věc. Ta existující OEM licence svázaná s použitím na fyzickém hw (koupená např. s notebookem) se nepřenáší do VM, i kdyby běžel na tom samém hw. I když teď poodhlédeme od těch zajímavých technikálií (kopírování ACPI tabulky atp.) nebo jestli použít FPP (retail licence fyzická nebo ESD) případně, jestli tam může být i levnější OEM.. MS prostě licenčně bere běh ve VM jako samostatnou věc.
Jedinou výjimkou jsou pak určité Windows Server edice, které si koupíte OEM se serverem a mají pak třeba povolený určitý počet spuštěných VM s licencovanými Windows, pokud tam běží pod Hyper-V.

8

Windows a jiné systémy / Re:Digitalni licence Win 11 a přesun na KVM

« kdy: 20. 09. 2025, 11:23:59 »

Přesto, že jste zmiňoval historku s chlapíkem a aktivací, tak to s OEM licencí (k vašemu počítači) oficiálně nejde.
Vícekrát jsem to během let i třeba s kolegy zjišťoval, například pro běh v Parallels na Macu, KVM/QEMU na Linuxu a odpověď byla vždy negativní. Pokud to má být licenčně v pořádku, potřebujete plnou retail licenci (cca 200 USD za Pro verzi).

Ale pokud se ptáte, jestli je tam technická možnost, tak za určitých podmínek nejspíš ano..
Pokud se jedná o skutečně OEM klíč od nějakého výrobce (např. HP, Lenovo..), tak je typicky vázaný na SLIC (software licensing) ACPI tabulku a metadata (manufacturer, sku atp.) z SMBIOSu.
Mrkněte se na odpovídající dokumentaci k libvirt nebo ekvivalent u čistého QEMU.
https://libvirt.org/formatdomain.html#common-os-element-configuration

Ta metadata z fyzického počítače získáte přes dmidecode. SLIC ACPI tabulku můžete vykopírovat celou z /sys/firmware/acpi/tables/.
Další možnost je pak tak, že je použitý OEM klíč už je v tabulce ACPI tabulce MSDM (tam se nechá najít jako plaintext).

Můžete si to zkusit nastavit ve VM, případně použít klíč a uvidíte, jestli se to chytne. Zkoušel jsem to pro zajímavost před lety (Windows 7, 10) a normálně jsem to rozběhl, Windows ve VM naběhly rovnou aktivované.

Já to v posledních letech moc neřešil, mám buď multiboot s Windows, nebo samostatný počítač. Když mám něco na testování, technickou podporu atp., tak různé verze Windows, co mám třeba v nějakých výchozích šablonách, ve virtuálech vůbec neaktivuji a je to v podstatě jako trial. Omezení nekativovaných Windows pro tohle použití nevadí, a jakmile to nepotřebuji, tak to smáznu a při příštích pokusech to vezmu načisto.

9

Sítě / Re:Cetin terminátor a port forwarding

« kdy: 15. 09. 2025, 21:35:18 »

Ale samozřejmě souhlas, v tomhle případě je QuickConnect určitě lepší nápad.

Dovolím si nesouhlasit, Quickconnect je příliš pomalý, nikdy plně nevyužil ani bandwidth běžných DSL připojení. Což při synchronizaci 100MB+ souborů je znát hodně.

To bylo míněno tak, že je to lepší nápad, než přímo vystavit webové rozhraní DSM do internetu (bez VPN). Ale nic, to je teď vedlejší debata.

Dost dobře nechápu proč se některým nelíbí provozovat VPN na domácím NASu a básní o 3rd party solutions. Chápu, že s DDNS je adresa "vystavená" komukoliv, to ale s veřejnou IP přeci odpadá? No a když mám otevřený 1 port na 1 službu ke které je mimo hesla potřeba ještě certifikát, tak to brute force útokům nemůže dát šanci. A nemusím se spoléhat na služby třetích stran.
Nejsem specialista, IT mám jako hobby (trochu z donucení), ale stále si myslím, že můj setup není špatný. Klidně mě ale vyveďte z omylu..

Služba, co poslouchá na veřejné adrese a nemá nijak omezné zdrojové adresy, je z principu přístupná komukoliv. Vůbec to nesouvisí s DDNS, to je jen záležitost překladu jména na adresu. Ale už se v tom upřímně trochu motáme

Za mě je to s VPN domů a veřejnou adresou dobré řešení, navíc získáte doma plnohodnotné připojení do internetu, bez dalšího překladu u ISP.

10

Sítě / Re:Cetin terminátor a port forwarding

« kdy: 15. 09. 2025, 12:41:58 »

A jak přesně pomůže, že místo https://mujtajnynas.quickconnect.to půjde útočník na https://1.2.3.4? VPN teoreticky nabízí menší útočný vektor (je vystrčená jediná služba, která je navíc celkem malá a měla by být security-first), takže tu chápu. Ale vystrčit ten NAS přímo ven mi v obecné rovině přijde horší, než mít to přes QuickConnect a podobné služby. Protože Synology, CloudFlare a další poskytovatelé těchto "zveřejni server zevnitř" služeb aspoň mohou detekovat nějaké large-scale útoky a něco proti nim dělat. Lokálně je na to člověk úplně sám.

Já jsem víceméně parafrázoval tazatele, který psal:

Dříve jsem používal Synology Quick Connect a zaznamenal několik pokusů o nabourání se do NASu. Naštěstí jsem měl 2FA, takže neúspěšných. Od té doby jsem nakonfiguroval VPN a vše jelo jak po másle odkudkoliv, dokud jsem nezměnil ISP za účelem vyšší rychlosti a nižší ceny.

A z mého pohledu je to přesně jak jste zmiňoval, ať už s OpenVPN nebo WG mám v tu chvíli vystrčenou službu, která je poměrně hlídaná z hlediska zabezpečení, poslouchá na jednom UDP portu a mám to plně pod kontrolou, plus ten tunel je vždy navázaný přímo bez relayování přes další veřejný server.
To že by služby z NASu (web rozhraní, SMB..) byly přímo přístupné z internetu, myslím, nebylo nikdy ani ve hře.
Ale samozřejmě souhlas, v tomhle případě je QuickConnect určitě lepší nápad.

11

Sítě / Re:Cetin terminátor a port forwarding

« kdy: 15. 09. 2025, 10:12:18 »

Nicméně jestli se nepletu, tak Synology má také službu QuickConnect, která umožňuje vzdálené připojení na NAS, i když je schovaný v lokální síti za NATem i CG NATem. Data jdou přes relay servery Synology.

Což přesně už výše zmiňoval, že nechce, protože už to předtím používal a někdo mu do toho z jejich veřejného cloudu bušil a zkoušel se připojovat.

12

Sítě / Re:Cetin terminátor a port forwarding

« kdy: 15. 09. 2025, 10:10:28 »

Přesně tohle je ovšem to, co mi vůbec nedává smysl. Proč se handrkovat a řešit nějakou veřejnou IP adresu kvůli VPN když tutéž VPN mohu mít někde na VPS, kde to všechno funguje tak nějak per design z principu a ještě je to jak flexibilnější, tak univerzálnější tak levnější...

Tak nějak ty základní nevýhody tu už padly (musí nakonfigurovat a udržovat další server v internetu, přidá to latenci, což je docela znát třeba při přímém použití CIFS/SMB mountů..). A ano technicky vzato ve VPS může rozjet i OpenVPN server s povolenou komunikací mezi klienty a správným routováním, na Synology je pak i OpenVPN klient, který se tam může připojovat.
Ale s tou flexibilitou nebo univerzálností záleží, co chcete.. pokud potřebuju mít veřejný hub s nějakou dobrou konektivitou a spojuju víc sítí dohromady, případně chci mít služby, co běží nezávisle na domácím připojení (viz třeba váš mail server), nebo si s něčím hrát, ano VPS dává smysl.
Ale zas pokud chci mít doma lepší připojení, co mi v budoucnu umožní forwardovat jakékoliv porty na libovolné zařízení uvnitř, zbaví mě CG-NATu (což je IMO ještě větší benefit než ta neměnná adresa, která se dá většinou obejít přes DDNS), tak dává smysl prostě připlatit, nemyslím, že je to tak zásadní cenový rozdíl (pár stovek za rok). Handrkovat se s nikým nemusí, stačí to objednat, zapnou to a příští měsíc to má jako další položku na faktuře.
Obecně ten CG-NAT bohužel neovlivní jen ty explicitně mapované služby z venku.. kolikrát to třeba u spousty služeb pouštěných zevnitř způsobí to, že se tiše přepne režim do nějakého kompletního relayování přes veřejný server místo rychlejší peer-to-peer komunikace. I když třeba služba nutně nepoužívá UPnP/PCP aby si je dynamicky otevřela na routeru, tak může používat UDP hole punching, který s tím dalším NATem po cestě už nezabere.
Týká se to třeba různých VoIP, teamspeaku a síťového hraní z PC nebo konzolí, ale i třeba už tady zmíněného ZeroTieru.
Podobně klasický use-case se seedováním torrentů.

13

Software / Re:Utilita du se chová divně nad NFS/BTRFS

« kdy: 14. 09. 2025, 14:10:45 »

Aha, už sis odpověděl sám mezitím

14

Software / Re:Utilita du se chová divně nad NFS/BTRFS

« kdy: 14. 09. 2025, 14:09:37 »

Ahoj. To je podle mě kvůli tomu, že ty btrfs subvolumy v NFS mountu mají vždycky stejný inode a společný device.
Porovnej si to přes výstup ze stat lokálně a přes NFS.
Takže to du nerozliší a ty položky, co mají stejný dev i inode, při procházení vyhazuje. Neznám teď konkrétní mechanismus, musel bych to někde hledat ve zdrojáku coreutils.. ale typicky se to dělá kvůli tomu, abys nezpracovával/nepočítal vícekrát položky, co jsou hardlinkované.

Myslím, že i proto je tam obecné doporučení ty subvolumy sdílet přes NFS zvlášť a přidat jim unikátní ID.
https://btrfs.readthedocs.io/en/latest/Interoperability.html#nfs

Ještě jinak ty du výstupy přes NFS bude chtít brát trochu s rezervou, pokud jsou v té struktuře třeba reflinky (soubory  sdílí extenty), což se podle mě projeví tak, že to spočítá víckrát.

15

Sítě / Re:winbox linux vs windows

« kdy: 12. 09. 2025, 13:38:38 »

Winbox používám na Linuxu od té doby, co to zveřejnili, teď mám z Flathubu 4.0beta30.
Používám to s více RouterBoardy, Hexy atp.
Jediné, na co jsem v některých předchozích betách narazil, bylo to, že blblo připojování přes Neighbors a MAC discovery (výběr nahoře select from:), ale jakmile jsem tam normálně uložil spojení přes IP adresu a používal Saved, tak to bylo v cajku.
Teď se zdá, že mi funguje se zmíněnou verzí i to discovery.