1
Hardware / Re:Doporučte notebook okolo 1000 eur
« kdy: 13. 04. 2025, 12:28:37 »
Byla řeč o HP Probook 460... pro doplnění, 465 je totéž s AMD.
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.
2
Sítě / Re:Tři tunely VPN s jednou veřejnou IP adresou
« kdy: 13. 04. 2025, 11:21:01 »
IP subnetting a statický routing 101, akorát obohaceno o VPN tunýlky... potřebujete zařídit, aby routery na těch dvou pobočkách měly směrovací záznam každý pro tu protější pobočku - ale protože nemáte na pobočkách statickou veřejnou adresu, tak jste si správně postavil doprostřed VPSku s veřejnou statickou adresou = třetí bod, router, který spojení zprostředkuje. Proto potřebuje mít směrovací záznamy pro subnety těch dvou poboček.
Dopingnete se z pobočkových routerů na VPSku skrz tunel?
Dopingnete se z pobočkových routerů na VPSku skrz tunel?
3
Sítě / Re:Výběr routeru pro provoz OpenWrt
« kdy: 13. 04. 2025, 07:35:01 »
@k3dAR díky za analýzu :-)
Tohle jsem taky našel, ale to bych chápal že vezme celej firmware = včetně binárních blobů, prostě všecko.
Já měl na mysli, zazálohovat / obnovit jenom konfiguraci, tzn. asi /etc/config.
Je fakt, že zazálohovat "všecko" je nadmnožina mé představy.
A řeší to i věci mimo /etc/config, tzn. věci typu, že člověk vyhodí vanilkový firewall a nacpe si tam svůj shellový skript, který dělá věci po svém.
Což nejde v komerčních firmwarech, které mají konfiguraci nějak "striktně sjednocenou", a potažmo ji umí samostatně jednotně zálohovat/obnovit...
Taky tenhle styl backup/restore "jedině všeho dohromady" odpovídá taky na dotaz, zda by nešlo udělat backup staré konfigurace, upgradnout firmware a loadnoat do nové verze starý konfig... = nešlo. Ne jedním kliknutím. Kdyžtak hezky svými prostředky, soubor po souboru. Člověka to nutí, aby přemejšlel, co dělá. Těžko proti tomu něco namítat.
EDIT: ad GUI pro backup/restore, samozrejme ma ;-)
CZ: Systém -> "Zálohovat / nahrát firmware"
EN: System -> "Backup / Flash Firmware"
URL: http://router/cgi-bin/luci/admin/system/flash
Tohle jsem taky našel, ale to bych chápal že vezme celej firmware = včetně binárních blobů, prostě všecko.
Já měl na mysli, zazálohovat / obnovit jenom konfiguraci, tzn. asi /etc/config.
Je fakt, že zazálohovat "všecko" je nadmnožina mé představy.
A řeší to i věci mimo /etc/config, tzn. věci typu, že člověk vyhodí vanilkový firewall a nacpe si tam svůj shellový skript, který dělá věci po svém.
Což nejde v komerčních firmwarech, které mají konfiguraci nějak "striktně sjednocenou", a potažmo ji umí samostatně jednotně zálohovat/obnovit...
Taky tenhle styl backup/restore "jedině všeho dohromady" odpovídá taky na dotaz, zda by nešlo udělat backup staré konfigurace, upgradnout firmware a loadnoat do nové verze starý konfig... = nešlo. Ne jedním kliknutím. Kdyžtak hezky svými prostředky, soubor po souboru. Člověka to nutí, aby přemejšlel, co dělá. Těžko proti tomu něco namítat.
4
Sítě / Re:Výběr routeru pro provoz OpenWrt
« kdy: 11. 04. 2025, 17:22:15 »Pokud zařízení konfigurujete přes UI, tak jsou většinou aktualizace bezproblémové. Problém může nastat, pokud se hrabete v konfiguračních souborech, protože s tím většínou nějaký migrační proces moc nepočítá. To je ale myslím problém prakticky všech OS obecně.
Skoro bych řekl, že LuCi je víceméně kabátek (možná ne zcela úplný) nad konfigurčními textovými soubory v /etc/config/* . Nezdá se, že má někde nějaký svůj další "configuration storage". Starou konfiguraci (textové soubory) je dobré si před updatem firmwaru zazálohovat. Protože jsou to textové soubory, dá se to provést hromadně skriptem pomocí scp nebo rsync. Nějak jsem nenašel možnost, že by backup/restore konfigurace byl možný přímo z LuCi GUI - opravte mě jestli kecám. Nějaké možnosti "podržet si předchozí konfiguraci" dává i samo OpenWRT. Má to své meze. Podrobnosti se dočtete v návodu - myslím že je docela pěkně zpracovaný.
Plyne mi z toho, že OpenWRT nedělá nějaký automatický "merge" distribučních konfigurčních souborů (šablon) s Vašimi úpravami. Údajně většinou stačí prostě zkopírovat staré konfigurační soubory. Opatrný postup by byl, nainstalovat novou verzi s čistou konfigurací, pouze si zadat IP adresu, pak si čistou konfiguraci stáhnout někam na pracovní stroj, a udělat "diff" proti Vaší předchozí upravené konfiguraci. (Nebo proti předchozí čisté konfiguraci ;-) Prostě si udělat představu o vývoji v upstreamu, a pak zapracovat svoje změny do nové konfigurace. Třeba Debian při dist-upgradu toto polo-automatizuje (ten diff Vám umí nabídnout sám).
Bohužel zcela obecně při změně verze OS dochází taky ke změnám v obsahu konfiguračních souborů. Čím větší změna verze, tím větší rozdíly lze očekávat :-) Mimochodem si všimněte, že OpenWRT jede svého druhu dvoumístný systém verzování. On vypadá jako třímístný, ale první dvě čísla jsou údajně letopočet a měsíc - toto dohromady je major verze. Na třetím místě je maintenance release / patchlevel. Takže pokud se týče kompatibility konfigurací, tak v rámci shodné major verze (při upgradu na vyšší patchlevel) bych se o konfiguraci relativně nebál - ale pozor na způsob interního zachování předchozí konfigurace "na požádání". V obecné rovině bych doporučil: zálohovat, dokud je co.
Určitě znáte zásadu, upgrade na novou verzi vyzkoušet na jednom kusu, zjistit co to přesně obnáší, jednak samotné přehrátí firmwaru, druhak co je případně potřeba ručně domasírovat v konfiguraci.
Ale tohle je obecná přiměřená opatrnost při správcování síťovin a OS.
Občas bohužel přijde nějaká zásadnější změna - třeba změna rozdělení disku... nebo nějaká změna která znemožní nouzový návrat na předchozí verzi firmwaru (cojávím, upgrade bootloaderu). Různé značky firmwaru se s tím potýkají všelijak, ale obecně bývá znát snaha, provést to zaživa automaticky a admina s tím zbytečně neobtěžovat. Pouze ho varovat, že je z nějakého důvodu ukrácen na svém svatém právu provést ústup na předchozí políčko.
5
Sítě / Re:Průzkum pokrytí signálem Wi-Fi
« kdy: 11. 04. 2025, 16:24:58 »
Ještě mě napadá, dát jenom jedno AP nad střed každé uličky, třeba do ní ještě svítit ležatou sektorkou, a na zhlavích nasázet přiměřeně daleko od sebe nějaká všesměrová ufa. Ve finále by byl počet AP v éteru méně přehnaný, ale snáz by docházelo k situacím, že bude mít klientský terminál jediné ufo nad uličkou zacloněné svou vlastní ještěrkou...
6
Sítě / Re:Průzkum pokrytí signálem Wi-Fi
« kdy: 11. 04. 2025, 16:06:20 »I tak byl vždycky na jednom frekvenčním kanálu vidět větší počet APček (třeba- a všech 80 sdílelo ESSID.
Mělo být: větší počet APček (třeba 8 ). Připletl se nezamýšlený emoji.
Si tak říkám, jestli tam jezdí ještěrky, nejlépe bateriové, tak bych umístil i nějaké repeater přímo na ještěrku. Ještěrka přecijen uveze lepší anténu, než nějaká Zebra., takže maník co s tím jezdí a běhá okolo toho by mohl být spokojen.
Hmm. Případně použít simultaneous dual-band rádio, chytit to na 5 GHz a předat lokálně na 2.4 GHz. Pokud by ten repeater měl nějaký trochu otevřený firmware, možná by se tam dalo něco nepatrně poladit v chování klienta (viz debata o roamingu). Ovšem bridging na klientu není na wifi samozřejmost, nabízí se několik kompromisních workaroundů (udělat na vozíku L3 subnet, případně ho schovat za NAT, nebo na L2 překlad MAC adresy, nebo rozjet na páteřním bezdrátu 4-adresní režim).
A mohla by s tím být i psina. Třeba když se zaparkujou vozíky při předávání šichty někde v řadě vedle sebe, tak by se občas nějaká Zebra chytila na APčko sousednímu vozíku :-) a jak by se rozjeli od sebe, tak by zebra musela odroamovat...
7
Sítě / Re:Průzkum pokrytí signálem Wi-Fi
« kdy: 11. 04. 2025, 13:36:30 »
Spoustu lidí už tady většinu bodů popsalo, asi se nevyhnu určité míře papouškování...
Kdysi dávno, v jedné daleké galaxii, jsem takový sklad taky zažil. Protože jsem tam měl průser s jedním terminálem, co jsme tam dodávali no... já znám jenom místa, kde jsem měl průser.
Wifi APčka / pokrytí tam tehdy dodal jeden místní integrátor, a podle toho co tu ostatní vyprávíte, tak zřejmě dost věděl co dělá, minimálně co do rozmístění APček. (Akorát když jsem se ho zeptal na 802.11r, tak kroutil hlavou, že o tom v životě neslyšel.)
Sklad je obecně prostor rozčleněný do velkého počtu úzkých uliček mezi "regálovými stěnami". Jak psali ostatní - ty regály se plní vším možným. V mém případě od palet a kontejnerů (plast/kov) a kovových klecí s plastovými výlisky, po velké díly lisované z kovových plechů. V podstatě má smysl, řešit viditelnost pouze v uličkách - a i tak je třeba jisté míry wishful thinking, protože fresnelova zóna bude narušená konstrukcí regálů.
V mém případě svítilo stávající řešení do každé uličky dvěma AP na stropě. APčka byla tuším přilepená zevnitř na střeše, a visela nikoli uvnitř uličky, ale nad prostorem "zhlaví", ovšem tak, aby vždycky dvě AP protí sobě viděla do uličky. Takže vozík s terminálem v uličce měl přímou viditelnost na dvě AP, a teoreticky to bližší AP mělo šanci protlačit uličkou signál méně rozbitý mnohočetnými odrazy od regálů. Kromě toho že terminál byl ve vozíku, anténu proutek měl přímo na svém těle a vždycky jedno z obou AP měl částečně zacloněné kabinou.
V prostoru zhlaví viděl samozřejmě vozík řadu APček - tuším jich tam bylo 40+40 = 80 kusů. Což se projevovalo např. tak, že v XP Embedded na tom PC-based terminálu, ve standardním systray appletu co ukazuje seznam viditelných ESSIDů a APček, přetékal tenhle seznam! Kupodivu ta věc pod kapotou nějak fungovala, ale orientovat se v tom moc nedalo. Tuším jsem tehdy šmahem všude tlačil proprietárního "supplicanta" od Atherosu, který se s tím prostředím dokázal popasovat o něco lépe, a poskytoval detailnější informace, co vidí v éteru. (Tenhle supplicant skončil s XPčkama.)
Dodavatel té infrastruktury se se mnou tehdy moc nebavil, ani se mu popravdě nedivím. V zásadě měl v ruce nějaký měřák co ukazoval sílu signálu - ukázal mi bargraf a řekl "hele plný počet čárek". APčka měly radom tuším nějaké "ufo", tj. v zásadě všesměrové antény. Rozhodně tam nebyla vidět snaha, mířit třeba do uličky "sektorkou položenou na bok". Ono u "skládaných patrových anténních soustav" s ostrou směrovosti podél osy skládání bych se trochu bál jevu šilhání podle frekvence. Jako že na každém kanálu by anténa mířila trochu jinam. Záleží na detailech konstrukce antény - zda jsou zářiče fázované navolno sériově, nebo "zaručeně soufázově" (hvězdicový rozbočovač a paralelní napájecí vedení o shodné délce - podle mého vzácný jev, je to konstrukčně složité).
Jo a jeli tam pásmo 5 GHz, tuším nějak odemčené včetně outdoorových kanálů, protože ta plechová hala s dvojitými sendvičovými stěnami stejně nic ven nepustila. Na parkovišti venku nešlo chytit vůbec nic. Kanály široké standardních 20 MHz, takže jich tam bylo v celém spektru k dispozici poměrně dost. I tak byl vždycky na jednom frekvenčním kanálu vidět větší počet APček (třeba - a všech 80 sdílelo ESSID. Vzhledem k tomu, že užitečný provoz nepotřeboval velkou průchodnost (tuším Telnet nebo SSH) tak moc nevadilo, že sdílení kanálu více AP snižuje efektivitu využití kanálu. Spíš byl problém, že zejména ve volném prostoru na zhlavích klient vždycky viděl větší počet AP s dobrým signálem, a klienti velice neochotně roamovali. Jestli s tím dodavatel pokrytí něco zkoušel dělat, jakože slézt se sílou signálu a nastavit výš práh pro kicknutí klienta... nevím. Spíš mám pocit, že naopak vnímali tohle "lepivé" chování klientů jako žádoucí, protože bez 802.11r se při roamingu snadno rozpadaly TCP relace, nad kterými běžel terminálový provoz. (Tuším tam byly kvůli častému roamingu statické IP adresy a možná nejeli WPA2, už nevím.) A pokud byla snaha počty roamingových skoků minimalizovat, tak dávají smysl taky všesměrové antény.
Sdílení frekvenčního kanálu více APčky není nutně tragédie, zejm. pokud se třeba povede uchodit "pouze short preambuli" a nejlíp ještě pustit beacony na vyšší než "základní béčkové" rychlosti. Našel jsem k tomu vcelku zajímavé povídání - beacony na vyšší rychlosti jednak zlepší efektivitu využití času v kanálu, ale mají ještě tu vedlejší potenciálně kladnou vlastnost, že na vyšší modulační rychlosti je AP vidět s horší rezervou odstupu signál/šum. Takže klienti ochotněji roamují. Údajně se dá nastavit beacon dokonce na rychlost vyšší, než je nejnižší konfiguračně povolená - v tom případě asociovaný klient protlačí užitečná data v poněkud rozsáhlejším prostoru, než ve kterém vnímá AP jako použitelné podle SNR na beaconech :-) Ale nikdy jsem s rychostí beaconů osobně nešachoval, takže třeba nevím, co tohle vyžaduje od klientů...
Modelovat pokrytí... jak už tady psali ostatní, obsah regálů modelovat moc nejde ani staticky, a navíc se neustále mění. Kromě toho ta prostorová dispozice (úzké uličky + velká zhlaví) je tak pitomá, že ani kdybyste měl dobře specifikovanou geometrii a materiály a obsah regálů, tak můžete trénovat s modelovacím softwarem klidně do smrti a k "akademicky rozumnému" řešení nedojdete :-D protože ta situace je prostě NEMOŽNÁ.
Takže asi nejlepší z ohavných kompromisů viz jak už psali ostatní. Svítit do uliček, a snažit se napomáhat rychlosti roamingu, aby nebyly výpadky na užitečných vrstvách komunikace.
Myslím, že tím je rozmístění APček v prostoru zhruba jasné... určitě bych se přimlouval, prokládat kanály v prostoru, aby AP na shodných a sousedních kanálech nebyla navzájem příliš blízko. Ale v tom prostoru na zhlavích se překryvu pokrytí na sdíleném kanálu stejně nevyhnete. O "buněčné plástvové struktuře" si můžete nechat jenom zdát... (Aby nakonec nevycházelo líp, dát potřebný počet AP na sdíleném kanálu prostorově naschvál co nejblíž k sobě, aby se dobře viděly navzájem. Dumám, jestli to není nakonec lepší varianta, než když se budou navzájem "tak trochu na dálku rušit".)
Svého času jsem se snažil, hrát si s anténkami. Skladba hardwaru mi to v té době umožňovala. MiniPCI-e rádijko, prutovou anténu jsem dával zvenčí, RSMA konektor buď do připravené díry v těle terminálu, nebo dokonce jsem si dal zvenčí "vinglík". A taky to mělo svoje mouchy. Měl jsem odsimulováno, že výbornou směrovou charakteristiku do skladu ("rozpažený trychtýř" s elevací asi 45 stupňů) a dobré přizpůsobení k 50 Ohmům má "tři čtvrtě lambda" pahýl = kus drátu. Ale tahle volná tvorba má řadu elektrických i praktických úskalí a detailů, ve kterých se skrývá pochechtávající se ďábel... radši nebudu rozvádět. Koupit to hotové je nakonec jedině správné řešení - a pár decibelů zisku navíc vlastně nehraje roli (pokud to hotové řešení wifi klienta výrobce vyloženě nezvoral). Chce to před první realizací otestovat na malém počtu kusů...
Ohledně toho jakou značku APček... ať poradí znalejší :-) Osobně mám rád OpenWRT, ale desítky kusů bych asi nechtěl spravovat jednotlivě a netuším, jestli k tomu existuje nějaký open-source centrální management...
Kdysi dávno, v jedné daleké galaxii, jsem takový sklad taky zažil. Protože jsem tam měl průser s jedním terminálem, co jsme tam dodávali no... já znám jenom místa, kde jsem měl průser.
Wifi APčka / pokrytí tam tehdy dodal jeden místní integrátor, a podle toho co tu ostatní vyprávíte, tak zřejmě dost věděl co dělá, minimálně co do rozmístění APček. (Akorát když jsem se ho zeptal na 802.11r, tak kroutil hlavou, že o tom v životě neslyšel.)
Sklad je obecně prostor rozčleněný do velkého počtu úzkých uliček mezi "regálovými stěnami". Jak psali ostatní - ty regály se plní vším možným. V mém případě od palet a kontejnerů (plast/kov) a kovových klecí s plastovými výlisky, po velké díly lisované z kovových plechů. V podstatě má smysl, řešit viditelnost pouze v uličkách - a i tak je třeba jisté míry wishful thinking, protože fresnelova zóna bude narušená konstrukcí regálů.
V mém případě svítilo stávající řešení do každé uličky dvěma AP na stropě. APčka byla tuším přilepená zevnitř na střeše, a visela nikoli uvnitř uličky, ale nad prostorem "zhlaví", ovšem tak, aby vždycky dvě AP protí sobě viděla do uličky. Takže vozík s terminálem v uličce měl přímou viditelnost na dvě AP, a teoreticky to bližší AP mělo šanci protlačit uličkou signál méně rozbitý mnohočetnými odrazy od regálů. Kromě toho že terminál byl ve vozíku, anténu proutek měl přímo na svém těle a vždycky jedno z obou AP měl částečně zacloněné kabinou.
V prostoru zhlaví viděl samozřejmě vozík řadu APček - tuším jich tam bylo 40+40 = 80 kusů. Což se projevovalo např. tak, že v XP Embedded na tom PC-based terminálu, ve standardním systray appletu co ukazuje seznam viditelných ESSIDů a APček, přetékal tenhle seznam! Kupodivu ta věc pod kapotou nějak fungovala, ale orientovat se v tom moc nedalo. Tuším jsem tehdy šmahem všude tlačil proprietárního "supplicanta" od Atherosu, který se s tím prostředím dokázal popasovat o něco lépe, a poskytoval detailnější informace, co vidí v éteru. (Tenhle supplicant skončil s XPčkama.)
Dodavatel té infrastruktury se se mnou tehdy moc nebavil, ani se mu popravdě nedivím. V zásadě měl v ruce nějaký měřák co ukazoval sílu signálu - ukázal mi bargraf a řekl "hele plný počet čárek". APčka měly radom tuším nějaké "ufo", tj. v zásadě všesměrové antény. Rozhodně tam nebyla vidět snaha, mířit třeba do uličky "sektorkou položenou na bok". Ono u "skládaných patrových anténních soustav" s ostrou směrovosti podél osy skládání bych se trochu bál jevu šilhání podle frekvence. Jako že na každém kanálu by anténa mířila trochu jinam. Záleží na detailech konstrukce antény - zda jsou zářiče fázované navolno sériově, nebo "zaručeně soufázově" (hvězdicový rozbočovač a paralelní napájecí vedení o shodné délce - podle mého vzácný jev, je to konstrukčně složité).
Jo a jeli tam pásmo 5 GHz, tuším nějak odemčené včetně outdoorových kanálů, protože ta plechová hala s dvojitými sendvičovými stěnami stejně nic ven nepustila. Na parkovišti venku nešlo chytit vůbec nic. Kanály široké standardních 20 MHz, takže jich tam bylo v celém spektru k dispozici poměrně dost. I tak byl vždycky na jednom frekvenčním kanálu vidět větší počet APček (třeba
- a všech 80 sdílelo ESSID. Vzhledem k tomu, že užitečný provoz nepotřeboval velkou průchodnost (tuším Telnet nebo SSH) tak moc nevadilo, že sdílení kanálu více AP snižuje efektivitu využití kanálu. Spíš byl problém, že zejména ve volném prostoru na zhlavích klient vždycky viděl větší počet AP s dobrým signálem, a klienti velice neochotně roamovali. Jestli s tím dodavatel pokrytí něco zkoušel dělat, jakože slézt se sílou signálu a nastavit výš práh pro kicknutí klienta... nevím. Spíš mám pocit, že naopak vnímali tohle "lepivé" chování klientů jako žádoucí, protože bez 802.11r se při roamingu snadno rozpadaly TCP relace, nad kterými běžel terminálový provoz. (Tuším tam byly kvůli častému roamingu statické IP adresy a možná nejeli WPA2, už nevím.) A pokud byla snaha počty roamingových skoků minimalizovat, tak dávají smysl taky všesměrové antény.Sdílení frekvenčního kanálu více APčky není nutně tragédie, zejm. pokud se třeba povede uchodit "pouze short preambuli" a nejlíp ještě pustit beacony na vyšší než "základní béčkové" rychlosti. Našel jsem k tomu vcelku zajímavé povídání - beacony na vyšší rychlosti jednak zlepší efektivitu využití času v kanálu, ale mají ještě tu vedlejší potenciálně kladnou vlastnost, že na vyšší modulační rychlosti je AP vidět s horší rezervou odstupu signál/šum. Takže klienti ochotněji roamují. Údajně se dá nastavit beacon dokonce na rychlost vyšší, než je nejnižší konfiguračně povolená - v tom případě asociovaný klient protlačí užitečná data v poněkud rozsáhlejším prostoru, než ve kterém vnímá AP jako použitelné podle SNR na beaconech :-) Ale nikdy jsem s rychostí beaconů osobně nešachoval, takže třeba nevím, co tohle vyžaduje od klientů...
Modelovat pokrytí... jak už tady psali ostatní, obsah regálů modelovat moc nejde ani staticky, a navíc se neustále mění. Kromě toho ta prostorová dispozice (úzké uličky + velká zhlaví) je tak pitomá, že ani kdybyste měl dobře specifikovanou geometrii a materiály a obsah regálů, tak můžete trénovat s modelovacím softwarem klidně do smrti a k "akademicky rozumnému" řešení nedojdete :-D protože ta situace je prostě NEMOŽNÁ.
Takže asi nejlepší z ohavných kompromisů viz jak už psali ostatní. Svítit do uliček, a snažit se napomáhat rychlosti roamingu, aby nebyly výpadky na užitečných vrstvách komunikace.
Myslím, že tím je rozmístění APček v prostoru zhruba jasné... určitě bych se přimlouval, prokládat kanály v prostoru, aby AP na shodných a sousedních kanálech nebyla navzájem příliš blízko. Ale v tom prostoru na zhlavích se překryvu pokrytí na sdíleném kanálu stejně nevyhnete. O "buněčné plástvové struktuře" si můžete nechat jenom zdát... (Aby nakonec nevycházelo líp, dát potřebný počet AP na sdíleném kanálu prostorově naschvál co nejblíž k sobě, aby se dobře viděly navzájem. Dumám, jestli to není nakonec lepší varianta, než když se budou navzájem "tak trochu na dálku rušit".)
Svého času jsem se snažil, hrát si s anténkami. Skladba hardwaru mi to v té době umožňovala. MiniPCI-e rádijko, prutovou anténu jsem dával zvenčí, RSMA konektor buď do připravené díry v těle terminálu, nebo dokonce jsem si dal zvenčí "vinglík". A taky to mělo svoje mouchy. Měl jsem odsimulováno, že výbornou směrovou charakteristiku do skladu ("rozpažený trychtýř" s elevací asi 45 stupňů) a dobré přizpůsobení k 50 Ohmům má "tři čtvrtě lambda" pahýl = kus drátu. Ale tahle volná tvorba má řadu elektrických i praktických úskalí a detailů, ve kterých se skrývá pochechtávající se ďábel... radši nebudu rozvádět. Koupit to hotové je nakonec jedině správné řešení - a pár decibelů zisku navíc vlastně nehraje roli (pokud to hotové řešení wifi klienta výrobce vyloženě nezvoral). Chce to před první realizací otestovat na malém počtu kusů...
Ohledně toho jakou značku APček... ať poradí znalejší :-) Osobně mám rád OpenWRT, ale desítky kusů bych asi nechtěl spravovat jednotlivě a netuším, jestli k tomu existuje nějaký open-source centrální management...
8
Sítě / Re:Natažení optiky v rodinném domě
« kdy: 06. 04. 2025, 09:32:33 »
Ohledně spotřeby a topení SFP transceiverů, co je vs. není v pohodě, velice záleží na okolnostech = nakolik kvalitně a v různých ohledech příznivě je provedena tepelná vazba SFP klecí do okolí. Na plošák, na šasi, na vzduch okolo. Jestli se v šasi pohne vzduch (nejlíp aktivně) atd. Máte-li pasivně konstruované zařízení, tak podtočený ventilátorek a vhodně nasměrovaný průvan dokážou divy. Rozdíly v tepelné vodivosti jsou s trochou péče klidně o řád.
Jakožto letitý bastlíř dávám palec nahoru za kritérium "udržím na tom prst" (mnozí kolegové se mnou budou nesouhlasit :-) a dodávám druhé kritérium "nesmrdí to horkem".
Jakožto letitý bastlíř dávám palec nahoru za kritérium "udržím na tom prst" (mnozí kolegové se mnou budou nesouhlasit :-) a dodávám druhé kritérium "nesmrdí to horkem".
9
Sítě / Re:Vodafone (exUPC) vs. PODA (GPON) Internet
« kdy: 06. 04. 2025, 08:33:33 »
Rozdíl mezi klasickou kabelovkou a PON operátorem je dodnes v historickém dědictví = přenosové technologii.
Prosím opravte mě, pokud náhodou kecám - detaily se vyvíjejí a já už "dělám do včel".
Klasická kabelovka si udržuje a postupně upgraduje svoji HFC síť, která je stavěná na analogový přenos celého pásma (přinejmenším v poslední míli). Ano i přes optiku se dá přenášet analogové pásmo, dělají se na to dokonce SFP transceivery apod. Smyslem je, dotlačit koncovým spotřebitelům co nejvíc služeb přes stávající metalické koaxové rozvody v domech a po sídlištích. Konstruovat paralelně k "televizní" HFC síti ještě PON (nebo klasický Ethernet, viz Teta v Ústí) je pro dominantní operátory neekonomické. Zdvojení nákladů, složitosti, koncové kabeláže... Proto klasická kabelovka posílá "internet" modulovaný něčím jako QAM skrz frekvenční kanály v televizním pásmu CATV.
Ta strmá asymetrie pásma u EuroDOCSIS (a před ním DOCSIS a stejně tak DVB-RCC / ETS 300 800) plyne částečně z fyzikálních vlastností/zákonitostí konstrukce upstream kanálu v HFC síti, kde zejména historicky ta síť na "opačný" směr nebyla stavěná, musela se dodatečně dovybavovat (výhybkami / obousměrnými splittery), uplink se provozoval (provozuje?) v pásmu desítek MHz kde je určitá hladina rušení, asi je znát i limit na vysílaný výkon koncovým zařízením (roli mohou hrát požadavky na cenu koncového modemu) - prostě to bylo vždycky peklo oproti downlinku, který si běží "tím správným směrem", na který byla HFC síť vždycky stavěná, centrální vysílače / zesilovače se vyplatí zkonstruovat trochu kvalitně s ohledem na výkon a linearitu (a pak je živit elektřtinou) apod.
V uvedeném EuroDOCSIS a spol. je kapacita uplinku dána také rozdělením vzácného frekvenčního pásma mezi downlink a uplink - a tady nepochybně hraje roli úvaha, že poměr down/up by měl vycházet ze statisticky pozorovaného poměru reálných datových toků. Je to prostě efektivní řešení / využití vzácného zdroje. A nepochybně domácí konzumenti mnohem víc sosají (dneska víc než kdy dřív) než uploadují. Takže se upstream nastaví jako hubenější, takže je pak omezená i špičková průchodnost pro uživatele, kteří by třeba uvítali víc taky směrem ven.
Na PON optice je sice taky frekvenční duplex, ale jde o dvě barvy světla (WDM) = surové kapacity pro data je dost a dost i v upstreamu. Tzn. kapacita je symetrická, byť sdílená více klienty, protože to médium je "point to multipoint". Zůstává jeden principielní detail, shodný pro EuroDOCSIS i PON: zatímco v downstreamu se provoz jednotlivým klientům rozloží klidně i prostým "řazením do fronty v egressu", upstream vyžaduje TDM / rezervaci vysílacího času apod. Toto ssebou nese určitou režii a latence (oproti plně duplexnímu přenosu bod-bod). Přesto pokud správně pozoruji, v dnešních PON technologiích jsou ty latence navrub TDM snad v jednotkách milisekund... to by mě jako retailového konzumenta už snad ani neuráželo ;-) Navíc ta PON síť je optická - jako signálový dráteník mám příjemný pocit už z toho, že neřeším rozdíly zemních potenciálů.
Prosím opravte mě, pokud náhodou kecám - detaily se vyvíjejí a já už "dělám do včel".
Klasická kabelovka si udržuje a postupně upgraduje svoji HFC síť, která je stavěná na analogový přenos celého pásma (přinejmenším v poslední míli). Ano i přes optiku se dá přenášet analogové pásmo, dělají se na to dokonce SFP transceivery apod. Smyslem je, dotlačit koncovým spotřebitelům co nejvíc služeb přes stávající metalické koaxové rozvody v domech a po sídlištích. Konstruovat paralelně k "televizní" HFC síti ještě PON (nebo klasický Ethernet, viz Teta v Ústí) je pro dominantní operátory neekonomické. Zdvojení nákladů, složitosti, koncové kabeláže... Proto klasická kabelovka posílá "internet" modulovaný něčím jako QAM skrz frekvenční kanály v televizním pásmu CATV.
Ta strmá asymetrie pásma u EuroDOCSIS (a před ním DOCSIS a stejně tak DVB-RCC / ETS 300 800) plyne částečně z fyzikálních vlastností/zákonitostí konstrukce upstream kanálu v HFC síti, kde zejména historicky ta síť na "opačný" směr nebyla stavěná, musela se dodatečně dovybavovat (výhybkami / obousměrnými splittery), uplink se provozoval (provozuje?) v pásmu desítek MHz kde je určitá hladina rušení, asi je znát i limit na vysílaný výkon koncovým zařízením (roli mohou hrát požadavky na cenu koncového modemu) - prostě to bylo vždycky peklo oproti downlinku, který si běží "tím správným směrem", na který byla HFC síť vždycky stavěná, centrální vysílače / zesilovače se vyplatí zkonstruovat trochu kvalitně s ohledem na výkon a linearitu (a pak je živit elektřtinou) apod.
V uvedeném EuroDOCSIS a spol. je kapacita uplinku dána také rozdělením vzácného frekvenčního pásma mezi downlink a uplink - a tady nepochybně hraje roli úvaha, že poměr down/up by měl vycházet ze statisticky pozorovaného poměru reálných datových toků. Je to prostě efektivní řešení / využití vzácného zdroje. A nepochybně domácí konzumenti mnohem víc sosají (dneska víc než kdy dřív) než uploadují. Takže se upstream nastaví jako hubenější, takže je pak omezená i špičková průchodnost pro uživatele, kteří by třeba uvítali víc taky směrem ven.
Na PON optice je sice taky frekvenční duplex, ale jde o dvě barvy světla (WDM) = surové kapacity pro data je dost a dost i v upstreamu. Tzn. kapacita je symetrická, byť sdílená více klienty, protože to médium je "point to multipoint". Zůstává jeden principielní detail, shodný pro EuroDOCSIS i PON: zatímco v downstreamu se provoz jednotlivým klientům rozloží klidně i prostým "řazením do fronty v egressu", upstream vyžaduje TDM / rezervaci vysílacího času apod. Toto ssebou nese určitou režii a latence (oproti plně duplexnímu přenosu bod-bod). Přesto pokud správně pozoruji, v dnešních PON technologiích jsou ty latence navrub TDM snad v jednotkách milisekund... to by mě jako retailového konzumenta už snad ani neuráželo ;-) Navíc ta PON síť je optická - jako signálový dráteník mám příjemný pocit už z toho, že neřeším rozdíly zemních potenciálů.
10
Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN
« kdy: 04. 04. 2025, 09:12:33 »U TP-Linků (vyjma jednoho, viz odkaz níže) to funguje pouze tak, že na routeru s veřejnou IPv4 spustíš OpenVPN server a na tento server se pak můžeš připojovat přes OpenVPN klienta, přičemž ze sítě klienta vidíš do sítě serveru - ovšem opačně to nejde! Neboli ze sítě serveru do sítě klienta vidět nelze. Řešilo se to u TP-Linku dost často, abych to nemusel celé rozepisovat, tak tady je odkaz: https://community.tp-link.com/en/home/forum/topic/637010
Já jsem viděl OpenVPN zapečené ve více komerčních firmwarech, a vždycky mě to nějak omezovalo v rozletu - oproti vanilkovému OpenVPN v dospělém Linuxu nebo v OpenWRT. Prostě má cosi do sebe, mít k dispozici necenzurovaný openvpn.conf a širší prostředí otevřeného Linuxu okolo. Třeba pokud mi nevyhovuje, jakým způsobem OpenVPN server pracuje s různými klienty (že se buď vidí navzájem, aniž by traffic prošel kernelem, nebo se nevidí vůbec - konfigurační volba) tak si můžu rozjet OpenVPN server ve více instancích, můžu si nad tím rozjet dynamický routing podle svého gusta apod.
11
Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN
« kdy: 02. 04. 2025, 21:27:27 »
Sry za reklamu, jsem jenom občasný spokojený zákoš: Forpsi má nejlevnější VPSku s Linuxem (tuším Debian) za 85 Kč měsíčně vč.DPH. To má veřejnou statickou IPv4 adresu a dá se na tom kutit ledacos. Doporučuji využít fail2ban minimálně na SSH (spíš na všecky služby, na které to půjde. Matně tuším, že na SSH je možná zapnutý už v počáteční šabloně).
A na ty tři routery bych se pokusil dostat OpenWRT.
Až si pohrajete s OpenVPN, VPSku můžete zrušit aby nežrala peníze - a to OpenWRT na routerech si třeba nechte.
A na ty tři routery bych se pokusil dostat OpenWRT.
Až si pohrajete s OpenVPN, VPSku můžete zrušit aby nežrala peníze - a to OpenWRT na routerech si třeba nechte.
12
Hardware / Re:Chyby řadiče NVMe
« kdy: 02. 04. 2025, 15:13:31 »
Přiblokovat napájení 3.3V pro ten slot, zkontrolovat chlazení velkých čipů (přepastovat). Zkusit mrknout do BIOS SETUPu, jestli by tomu NVMe slotu nešel vnutit pomalejší režim PCI-e. A stejně jestli je tam někde vakl v signálových cestičkách a kuličkách, tak tomu nepomůže ani svěcená.
13
Server / Re:Jak řešíte emaily pro lidi ve firmách?
« kdy: 01. 04. 2025, 11:38:34 »
BTW je docela řehole a čím dál víc známka punku, provozovat si svůj mailserver on premises na svém vlastním hardwaru. Zároveň je velká pohoda, když máte vlastní barák a dost místa v serverovně (třeba protože nesídlíte v Praze), takže neřešíte, jestli server zabere 1U nebo 4U, a nic Vás netlačí do vysokých GHz a velké spotřeby...
Ale ono popravdě i 1U někde v kvalitním venkovském telehousu může být velmi v pohodě cenově i "prostorově" pro provoz svého mailserveru.
Takže ohledně mailů neřešíte, jestli mailbox konkrétního jednotlivce zabere na disku 2 GB nebo 100 GB. Prostě jednou za čas vyměníte nebo přidáte disky. Zvolíte si IMAP démona a storage back-end takový, aby neměl sklon se zhroutit do sebe, aby škáloval přiměřeně velikosti firmy a dal se gramotně zálohovat...
A je asi čím dál větší vzácnost mít zaměstnavatele, který tuhle Vaši činnost ocení. A asi těžko si to obhájíte jako jedinou náplň práce :-(
Ale ono popravdě i 1U někde v kvalitním venkovském telehousu může být velmi v pohodě cenově i "prostorově" pro provoz svého mailserveru.
Takže ohledně mailů neřešíte, jestli mailbox konkrétního jednotlivce zabere na disku 2 GB nebo 100 GB. Prostě jednou za čas vyměníte nebo přidáte disky. Zvolíte si IMAP démona a storage back-end takový, aby neměl sklon se zhroutit do sebe, aby škáloval přiměřeně velikosti firmy a dal se gramotně zálohovat...
A je asi čím dál větší vzácnost mít zaměstnavatele, který tuhle Vaši činnost ocení. A asi těžko si to obhájíte jako jedinou náplň práce :-(
14
Server / Re:Jak řešíte emaily pro lidi ve firmách?
« kdy: 01. 04. 2025, 11:20:29 »Tak v DS ti taky vsechno smaznou po 3 mesicich zejo ... at chces nebo ne. Nejaka smlouva, stavebni povoleni, soudni rozhodnuti ... nac bys to jako potreboval.
V my bubline se obcas resi, co si kdo s kym mailoval pred 5+ lety.
Občas mě zahřeje u srdíčka, když se podívám do historie emailů, o čem jsem se kdy bavil s konkrétním člověkem/zákazníkem, nebo jestli jsem už někdy řešil konkrétní produkt / problém / téma... A je psina odpovědět na e-mail ve stylu "jasně, vy jste u nás před 15 lety koupil toto, takže s tím teď máte následující problém" nebo "ano Vás znám z téhle firmy, a řešili jsme spolu tohle... mezitím se technologie posunula a teď umíme tohle..." a je zajímavé pozorovat, jak se ti lidičkové většinou nemění, je na ně spoleh :-)
15
Bazar / Re:Darujem rôzne SCSI a HBA radiče
« kdy: 01. 04. 2025, 10:35:11 »
hmmmm.... měl jsem svého času jako domácí počítač 486DX2/50 se serverovým motherboardem a EISA. Byly v tom asi 3 EISA karty vč. SCSI řadiče od Adaptecu. Dneska by to byl jednoznačně muzeální exponát... ale kdo to má skladovat. Šel do šrotu asi před 20 lety.
Ten Mylex DAC960 je podle mého košer HW RAID.
Jestli se mi po něčem nestejská, tak je to paralelní SCSI a jeho vakly v konektorech a kabelech, které se v průběhu let stárnutím materiálu postupně množily.
Ten Mylex DAC960 je podle mého košer HW RAID.
Jestli se mi po něčem nestejská, tak je to paralelní SCSI a jeho vakly v konektorech a kabelech, které se v průběhu let stárnutím materiálu postupně množily.
