Příspěvky

511

Sítě / Re:Vyplatí se optika?

« kdy: 12. 03. 2021, 22:56:39 »

Velcí operátoři internetových služeb pro SoHo segment (pro drobné zákazníky) a jejich dodavatelé technologií mají hluboce zakořeněný sklon a princip fungování: postavit poslední míli zásadně jako sdílené L1 médium, a navěšet na jediný segment co nejvíc zákošů. Původně bylo zjevnou motivací, vydojit co nejvíc peněz ze stávajících metalických rozvodů telefonu a kabelovky - a přestože kabelovčí páteř má dnes docela velký podíl optiky (nad kterou se ještě pořád 1:1 analogově moduluje rádiové pásmo?) a přestože DSLAMy jsou dnes už málem před barákem (a vede k nim optika) tak stejně pořád architektura té poslední míle znamená, že jsou tam zákazníci natěsnaní, a čím těsněji, tím líp. A stejným stylem se staví masový optický SoHo internet - GPON.

Všechny tyhle technologie mají společné, že ta poslední míle je "point to multipoint". Jedna ústředna/headend/centrála se baví s větším počtem účastníků - ovšem ti se přímo na L1 nebaví navzájem mezi sebou. Plynou z toho také některé aspekty asymetrie přenosu, který je pro SoHo služby charakteristický. Ony jednak tyhle technologie pro "residential subscribers" šetří vzácným pásmem (kapacitním a také frekvenčním) a asymetrické rozdělení pásma je dáno racionální úvahou, že takto nakloněné jsou reálné datové toky, generované účastníky. Druhá věc ale je, že zatímco ve směru "downloadu" je jediná fronta TX paketů na centrálním zařízení (DSLAM, cable headend apod.) tak opačným směrem (upload od účastníka vzhůru do sítě) se to hejno účastníků musí nějak střídat o sdílený uplinkový kanál, hezky už na první vrstvě. Kvůli efektivitě toto nelze řešit na bázi prosté detekce kolizí - naopak, uplink musí běžet v nějakém časovém multiplexu (TDMA) - ovšem přenos skrz cyklicky přidělované timesloty citelně zvyšuje latence uplinku. Abych nekřivdil ADSL, tam má každý účastník svoje dráty na ústřednu - ovšem i tady je v uplinku citelně složitější, všechny účastníky tam naskládat, a to kvůli přeslechům mezi páry... takže vectoring atd. A PR masáž potenciálních zákazníků apod.

A přitom jsou docela velké místní kabelovky a ISP, jako třeba v Ústí Teta, kteří tahají po sídlištích optiku a na ní *symetrický ethernet*. Poslední míle není na L1 sdílená mezi účastníky, a to ani v uploadu. Prostě symetrický přenos, point-to-point, full duplex. Žádné TDM, které by zvyšovalo latence. Jenom frontování v aktivních prvcích. Poslední míle na gigovém ethernetu má latenci řádově v nízkých dvouciferných mikrosekundách, navíc symetrickou... a pokud ISP není držgrešle, tak i dál směrem do internetu zpoždění narůstá s každým IP hopem pomalu a rovnoměrně... Kdo doma okusil připojení k internetu přes symetrický Ethernet, ten se bude DSL, DOCSIS a GEPONu už navždycky jenom smát...

512

Sítě / Re:Nějaký devboard či box s 1×10GE a aspoň 2×1GE porty?

« kdy: 12. 03. 2021, 22:05:37 »

Na ty samotne SFP jsem davneji delal editor (hw/sw), takze to lze samozrejme pohackovat kdyz to nekdo potrebuje

Ona se ta "SPD EEPROM" dá nějakým generickým způsobem změnit? Jako že je otevřená pro zápis?

513

Sítě / Re:Nějaký devboard či box s 1×10GE a aspoň 2×1GE porty?

« kdy: 12. 03. 2021, 21:57:35 »

Stale mam spise vizi nejake "krabicky". Napriklad
Mikrotik. Ten je ale zaseknuty na RouterOSu,
jak jsem vyrozumel z hledani po netu.

Nojo... podle toho co vidím, CRS305 nemá zatím podporu v OpenWRT...

514

Distribuce / Re:DVB-T na Ubuntu 20.04 LTS

« kdy: 11. 03. 2021, 14:08:21 »

Protože jsem asi předloni, podobně jako Marty, nenašel rozumný návod, napsal jsem si svůj... [/self-promotion]

Díky, mě už snad začlo i bavit, že mi to nefunguje... Bůh ví, kam se ještě dostanu

Tobě ten web funguje? I když odkliknu neplatný certifikát tak dostanu 404ku:

Not Found
The requested URL /htpc/htpc.htm was not found on this server.

Děkuji za upozornění a potenciální námět ke zlepšení... HTTPs jsem na tom freewebu nikdy neřešil, vždycky jenom HTTP. Na HTTP mi to normálně funguje. Jestli se budu hodně nudit, zkusím se podívat, jestli tam Seznam vůbec HTTPs umožňuje, a pokud ano, tak zač je toho loket. Ale kupovat certifikát na to momentálně určitě nebudu :-)

515

Distribuce / Re:DVB-T na Ubuntu 20.04 LTS

« kdy: 11. 03. 2021, 10:38:44 »

Na Installfest2021 mal o prijme DVB-T2 prednasku Ondrej Caletka, mozno tam najdes odpovede ktore hladas.

https://www.installfest.cz/if21/program.html

https://youtu.be/Kp5ZpgyKl-M

Stream od 8:27:00

Děkuji Váňovi za odkaz a panu Caletkovi za bezvadnou přednášku - možná trochu subjektivní, ale každopádně technicky hodně fundovanou, našel jsem si tam spoustu šťavnatých podrobností, které jsem neznal :-) Do záznamu, přednáška pana Caletky začíná představením a historickým ohlédnutím už v čase 8:00:00, uvítací banner asi o minutu a půl dřív.

Troufnu si tvrdit, že některé zajímavé a relevantní oblasti (kde jsem třeba zase já prošlapával slepé uličky, na pozadí svých subjektivních motivací) jinak skvělý přednes pana Caletky pomíjí :-) a dovolil bych si trochu doplnit. Zároveň si v témže duchu troufnu tvrdit, že v přednášce pana Caletky nenalézám odpovědi na některé otázky tazatele v tomto vezdejším vlákně :-) a nabídnu svou odpověď.

Poslouchal jsem místy na půl ucha (když se mluvilo o věcech, které cca znám) ale mám pocit, že pan Caletka zcela pominul VDR, až na jednoslovnou zmínku v seznamu. Podle mého zajímavý software, a ačkoli je interně taky rozdělený na client/server (zobrazovací front-end je oddělený proces), tak je to podle mého asi nejblíž stylu, na který se ptal Marty: spustím, přepínám programy, chová se to jako televize, můžu si i něco nahrát na HDD, nějaký ten timeshift apod. Základ VDR je živý projekt, který dostává pravidelné aktualizace. Toto bohužel nelze tvrdit o mnohých jeho 3rd-party pluginech, ale to je asi přirozený života běh...

Protože jsem asi předloni, podobně jako Marty, nenašel rozumný návod, napsal jsem si svůj... [/self-promotion] - link ukazuje naschvál na kapitolu o použitém softwaru. Můj text popisuje stav z roku 2019/2020. Od té doby vyšlo pár nových verzí různých SW věcí, bohužel možná nikoli intelových firmwarových blobů pro Gemini Lake IGP :-/ což se ale Martyho patrně netýká.

Osobně jsem asi před rokem dojel na nějaké nedodělky v zobrazovacích frontendech VDR pro VAAPI na hardwaru Intel Gemini Lake (jde o HW akceleraci H.265 - nebylo to v té době stabilní), měl bych se na to znova podívat :-)
Osobně jsem kompiloval skoro všecko ze zdrojáků, v té době VDR 2.4.0 a řetízek grafických závislostí (a kernel kvůli driverům pro dongle). Vývoj VDR i distribucí od té doby pokročil, nové kernely mají drivery pro více donglů, DVB-T2 se jistě taky v distribucích obecně stabilizovalo - zejména v čerstvém Ubuntu už bych čekal, že nebude potřeba tolik ručních rekompilací.

Mě osobně úplně míjí klasický balík command-line utilit dvb-tools. Párkrát jsem některé tooly použil, když jsem se učil ladit (= skenovat pásmo), nebo jsem něco debugoval, chtěl jsem si v příkazovém řádku naladit tuner a pustit si nějaký ukecaný výpis co se děje pod kapotou... ale reálně pro naladění a přehrávání TV tyto tooly nejsou potřeba. Což jsem samozřejmě zjistil až poté, co jsem si je všechny podle dávných zaprášených návodů dost důkladně osahal a odložil.

Marty se ptal konkrétně na w_scan, v Debianu samostatný balík, mimo "mini-ekosystém" dvb-tools. Kromě toho, že w_scan tuším nějak závisí na "seed souboru" vytvořeném pomocí dvb-tools (nebo naopak? už nevím) je w_scan zastaralý, neudržovaný a obsahuje bugy resp. "features", které mohou dávat smysl při brodění se milionem DVB-S transpondérů, ale jsou zcela padlé na hlavu při skenování pásma DVB-T2 (detekce a přeskakování duplicitních frekvenčních kanálů). Prvním pokusem o nápravu byl fork w_scan2, který ovšem také nedopadl stoprocentně. Osobně pro DVB-T2 vřele doporučuji další fork/work-alike zvaný t2scan, který konečně dělá to, co v DVB-T2 dělat má.
Konkrétně je t2scan velice užitečný pro pořízení počátečního seznamu kanálů pro VDR. Jedná se o textový soubor, který lze ručně přetřídit a promazat nejsnáz asi v textovém editoru (co řádek, to kanál). VDR má následně plugin zvaný tuším Wirbelscan, který si takto vytvořený seznam umí už sám dále spravovat / aktualizovat, jednak proskenovat na vyžádání celé pásmo, jednak tuším jede kontinuálně a reaguje průběžně na změny v obsahu sledovaných muxů.

Jestli máte někdo osobní kontakty na relevantní package maintainery Debianu a Ubuntu, zkuste je prosím inspirovat, že w_scan je už vážně ostuda, a že době odpovídá daleko spíš t2scan.

Na tohle se Marty neptal, ale když už jsem se tady rozjel: pan Caletka v dotazech na závěr přednášky zmiňuje, že si kdysi koupil z Číny dongle Mygica T230C, který ho nepřesvědčil svou nevalnou citlivostí a provozními výsledky. A doporučuje RPI DVB-T hat. No a já osobně to mám obráceně :-) RPI mi přijde jako podivná platforma, která na to jak málo je vybavená periferními porty, tak se dost přehřívá a má další nectnosti. Osobně se držím x86 a tam je mi samozřejmě RPi/Arduino header k ničemu. A pokud se týče USB DVB-T donglů, tak jako jednu konkrétní dlouhodobě dostupnou variantu bych zmínil Abacusem dovezenou Evolveo Sigma T2 alias Mygica T230C-v2, které mám dva kusy, a při té bídě, která u nás doma panuje v příjmu na STA, se drží myslím docela statečně. Mimochodem tuner a demodulátor této aktuální revize jsou od Silicon Labs. Konkurenční dongly s front-endem Sony jsou hůře dostupné a vůbec vypátratelné :-(

Mám vypozorováno, jaká je zhruba minimální úroveň CNR (a méně podstatná RSSI), při které je příjem bezvýpadkový. Tyto statistiky lze zjistit z command-line toolů, ale také (pro mě především) přímo z VDR, nejlépe s pluginem femon, který umí zobrazit fůru statistik ve svém vlastním menu. Tuším některé front-end pluginy VDR umí CNR zobrazit jako součást svého ladícího výpisu jako overlay nad běžícím obrazem. "Práh použitelnosti signálu" se podle empirických pozorování vcelku shoduje s reálným chování různých televizí, které jsem měl tu čest v baráku potkat - všelijaké Samsung, LG apod. Tzn pokud se týče T230C2, doporučuji neškaredit se na dongle, ale především si udělat v rámci možností pořádek v anténní soustavě, a také si zanadávat na QAM256 (DVB-T2), shůry nám danou vezdejší. Bohužel mám pocit, že výpadky MPEG paketů způsobují "pixelsalat" v HW akcelerovaném přehrávání H.265 na hardwaru Gemini Lake - ale to se taky možná pletu :-) Měl bych se na to znova podívat.

A ještě k poznámkám pana Caletky o grabování MPEG streamu z UDP do souboru na disk, vs. bloková a VM vrstva linuxu... klíčové slovo v přednášce bylo tuším dirty_expire_centisecs. Před lety jsem se v tom taky trochu nimral a ta problematika je myslím mírně složitější. Laditelných sysctl proměnných je tam víc, a kromě VM se do chování storage promítá také použitý scheduler, jeho specifické demence a jeho konfigurace = štelovatelná kroutítka. Jsou tam dohromady snad tři patra frontování a mezi nimi dvě patra expirací, jenom v rámci blokové vrstvy a IO scheduleru (tzn. nepočítaje FS). Těmito prostředky se dá writeback hodně poladit a popotáhnout k obrazu svému. Za těch pár let od mého ublognutí nějaká kroutítka přibyla a tuším došlo k prořezu dostupné množiny schedulerů, ale ledacos zůstává při starém - třeba deadline scheduler je tuším nadále k dispozici. Všiml jsem si, že třeba instalaci Linuxu nebo kompilaci kernelu, na stroji s pár GB RAM, lze dodnes výrazně zrychlit, pokud blokové vrstvě dovolíte využívat víc RAM a delší expiraci writebacku. A pak je otázka, zda by zmiňovaný user-space tool, použitý ke sběru paketů ze sítě a pro zápis na disk, nezasloužil "důkladnou předělávku". Což pokud se jedná o pár relevantních řádek v céčku, nemusí být zase tolik práce. Rozvláknit a zvětšit buffer. Pokud je ten tool ve stávající podobě natolik dementní, že v jednom vlákně střídavě přijímá pakety a provádí blokující zápis na disky, nejlíp s nějakým flagem který působí jako bariérová operace v řetízku front na disk IO, tak je dementní především ten user-space tool, spíš než linuxový VM/IO subsystém a jeho writeback (jakkoli IMO dodnes i pro tuto oblast platí, že je škoda rány, která padne vedle). Abych tolik nekřivdil blokové vrstvě a scheduleru, on filesystém má svoje vlastní potřeby, kvůli udržení konzistence, jak řadit zápisové operace a vkládat tu a tam povinně bariéru. Takže ve výsledku nejlepší postup je: psát aplikace tak, aby si bufferovaly podle své potřeby, a mohly nechat těch několik storage vrstev, ať se snaží jak nejlíp umí, za podmínek spletitého kompromisu různých požadavků na průchodnost a spolehlivost.

516

Sítě / Re:Nějaký devboard či box s 1×10GE a aspoň 2×1GE porty?

« kdy: 10. 03. 2021, 16:42:55 »

Staci chvili hledat:
https://www.supermicro.com/en/products/motherboard/X10SDV-12C-TLN4F+

Jojo, ta má plnotučný a relativně úsporný 14nm Broadwell Xeon, 45W. Ty dva 10Gb porty vytažené ze SoCu vedou do SFP+ šachet.

Ještě jsem našel rodinku pár kousků s 14nm ATOMem C3000 series (Denverton):
https://www.supermicro.com/en/products/motherboard/A2SDV-8C-TLN5F
https://www.supermicro.com/en/products/motherboard/A2SDV-12C+-TLN5F
https://www.supermicro.com/en/products/motherboard/A2SDV-16C-TLN5F
SoC má TDP 17-31 W , podle počtu jader (8/12/16).
Onboard 4x 10GBase-T Ethernet = metalika a až v datasheetu čipu X557-AT4 se dá dočíst, že by to snad mělo na metalice podporovat 100/1G/10G.
Formát těch desek je lehce úchylný Flex-ATX = o něco menší než microATX, soudělné díry.
Bohužel v Mini-ITX je od tohoto výrobce k dispozici jenom ATOM s 2x 1Gb.
Jako skříň na Flex-ATX nejsnáz asi nějaký microATX minitower.

517

Studium a uplatnění / Re:Kam jako programátor po 50 letech?

« kdy: 10. 03. 2021, 00:12:15 »

No já jsem vážně zvědavej, co budou dělat programátoři řekněme z generace Husákových dětí, plus mínus pár let, kteří si zažili porevoluční nástup PC v jinošském věku, celé si to prošli atd. - teď je jim kolem 45, tzn. do řádného důchodu to máme asi za 20 (já sám se za programátora nepovažuju) - tzn. jak bude branže vypadat za 20 let. Podle mého proběhla v minulých třeba dvaceti-třiceti letech taková exploze různých softwarových projektů, komerčních i otevřených, že pro "údržbáře a opraváře starších věcí" bude práce spolehlivě do penze. Škoda jen, že výrobci komerčního softwaru (OS, vývojových prostředí) naschvál zavírají vrátka za starými věcmi :-)

Vybavuju si asi dva staré machry, jeden byl databázista, druhý je integrátor špičkového průmyslového MaR (real-time řízení s vysokou přesností a rychlou odezvou) - které jejich klienti nechtějí/nechtěli pustit do důchodu! Lidi o 20-40 let starší než já, kteří k PCčkům přišli už ve fotrovském věku, a v dobách kdy jsem já "tahal kačera" v pascalu apod. v 90.letech, tak oni ve vývojových prostředích té doby *vyšívali* komerční aplikace, nad kterými mně po letech klesá čelist, zejména když mě nechají nahlédnout do zdrojáků.

Taky se trochu uklidňuju, možná nepodloženě, že pořád nejsme tak bohatí, aby nás spláchla šmahem bangalorizace, jako se to stalo kolegům v USA a asi i dalších západních zemích. Mám v dohledu pár firem v Německu, Švédsku apod. kde se mladí kluci snaží něco vytvářet (embedded SW/HW) a ceny jejich výrobků jsou citelně výš, než u asijské konkurence. Prochází jim to jedině v případě, že ty evropské výrobky jsou jasně lepší než asijská konkurence, že mají řádově lepší support atd.

Mezi dodavateli a bývalými kolegy znám pár starých machrů, mimo softwarové odvětví, ale řekněme ve slaboproudé elektronice a sousedních oborech, od kterých jsem dlouhá léta sosal znalosti a zkušenosti, a oni vždycky rádi poradili a poklábosili. A nemám pocit, že by se ke konci před důchodem už nudili - spíš naopak.

V zásadě bych řekl, že nemůžou všichni všechno umět a nemůžou všichni všechno stíhat. A když se v práci neflákáte a pracujete podstatnou část pracovní doby hlavou, tak Vás těžko nějaký mlaďas dožene a převálcuje. Naopak třeba budete mít před důchodem problém, komu předat řemeslo, slibně rozjetou živnost apod.

518

Server / Re:SAN - profesionální řešení okolo 50 tisíc, resp. do 100 bez disků

« kdy: 09. 03. 2021, 17:13:10 »

Omluva za troufalou exhumaci, spadl mi před chvilkou do schránky SPAM od německého Starline (v AJ) kde werbují na nějaký live webinář zdarma na téma harddisky/storage a CEPH... moc od toho nečekám, ale asi se ze zvědavosti přihlásím. Já sám zrovna z téhle firmy nic nemám, a nechci sem umísťovat link, jednak protože reklama ve free fóru, jednak přihlašovací link nevisí u Starline volně na webu. Pokud by to někoho zajímalo tak odpovím na SZ. Když mi moderátor toto smahne tak vím za co, omlouvám se a uvítám feedback, jestli jsem tentokrát už za čárou :-)

519

Sítě / Re:Sháním 100Mbit/s ethernet HUB (opravdu HUB, ne switch)

« kdy: 05. 03. 2021, 22:45:23 »

Správně - duplicitní MAC adresa je podstatou potenciálního DOS útoku.

Pokud vam jde o bezpecnost / SLA, tak snad mate na koncovych portech sve infrastruktury nastaveny seznam povolencyh MAC, ne? Tudiz jedna se tam dostane, druha uz nikoliv.

To ano. Pokud ovšem nemáte nějaký legitimní provoz, který používá pár "well known" unicastových MAC adres, které jsou potažmo shodné v každé další L2 síti. Jsem schopen ve svém archivu dohledat zmínky o historickém průmyslovém protokolu "ABB Masterbus 300", ale pokud vím tak nebyl sám.

520

Server / Re:GRUB na HW RAIDu

« kdy: 05. 03. 2021, 22:39:02 »

Z mdraid-u nenabootuje.
...
/boot/EFI

Možná by stálo za proti-otázku, zda dotyčný server podporuje legacy BIOS boot. V tom případě lze z MD RAIDu bootnout bez problému, dokonce tuším grub pozná MD mirror a umí si v něm nalézt FS (/boot). Pravda je, že legacy BIOS boot jde jenom z disku <= 2 TB, protože legacy BIOS nezná GPT.

521

Sítě / Re:Sháním 100Mbit/s ethernet HUB (opravdu HUB, ne switch)

« kdy: 05. 03. 2021, 14:19:37 »

Ještě technická poznámka, switch nevidí tutéž MAC adresu současně na více rozhraních, ale vždy jen na jednom, na tom, odkud se mu ozvala naposledy; viz všelijaké útoky proti switchům (bez ochrany).

A teď si představte, že tam třeba jedou dvě TCP spojení, dva stroje downloadují. Sice žijí ve dvou různých VLAN, ale provoz prochází jediným switchem. Střídají se: jeden klient pošle serveru ACK, druhý pošle serveru ACK, server prvnímu pošle kus payloadu a bác: MAC adresa ve switchi (L2 FDB) zůstala naučená směrem k druhému klientovi, ale ten je ve druhé VLAN, takže v první VLAN dojde k zahození paketu... dokud se první klient znovu neozve "haló, já jsem pořád tady"... a má chvilku šanci dostat nějakou tu retransmisi, pokud se mezitím neozve druhý klient...
No a tohle si dělají navzájem.

Chová se to trochu podobně, jako kolidující IP adresy, akorát při dropnutí paketu na L2 není šance, že by se aspoň vracely odesilateli ICMP unreachables (když dorazí paket na neotevřený port) apod.

Správně - duplicitní MAC adresa je podstatou potenciálního DOS útoku.

522

Studium a uplatnění / Re:Jak zlepšit úroveň němčiny?

« kdy: 05. 03. 2021, 08:24:58 »

Další důkaz, že germanizace nabírá na síle...fuj!
Nedokážu si představit němce jak řeší na fóru, jak zlepšit svou češtinu.

Ono když berete konkrétně němčinu jako jeden ze dvou / tří / čtyř cizích jazyků, které v různé míře ovládáte, tak ta hrůza konkrétně z germanizace tak nějak vyprchá :-) A začnete třeba vnímat, jak dodnes ve vlastní produkci tuzemských filmů a televizí němec = špatný člověk, abych použil eufemismus. Ta šablona je skutečně trvanlivá. Stále další a další příběhy z předmnichovského období a protektorátu. A veškerá cizí produkce se dabuje...

Ze širší perspektivy samozřejmě chápu,  že v našem zeměpisném prostoru je dodnes těžké, oprostit se ve vztahu k cizím jazykům od paušálních historických geopolitických mindráků.

Možná mám kliku, že v práci denně potkávám Němce spíš jako zákazník, zcela vyjímečně jako dodavatel. A při anonymních debatách různě v internetech často sotva tušíte, jaký komu zobák narost.

Neuvědomuju si, že bych někdy potkal "německého roota". Zhruba k tomuto tématu si vybavuju výživný časopis CT (www.ct.de) , ale to je placené papírové periodikum. Možná německým IT geekům přijde divné, zakládat si domorodé debatní fórum, když se můžou bavit zcela bez zábran na globálních fórech anglicky. Co jsem zatím potkal, asi nejblíž "domorodému linuxovému fóru" je pro mě vdr-portal.de - řeší se tam převážně televizní software. Lidi stavěj HTPCčka a malinové TV headendy apod. a kecaj o tom, na tomto fóru se baví mj. několik pobočníků velkého KLS, autora VDR.

523

Odkladiště / Re:Co s podvodnou doménou

« kdy: 04. 03. 2021, 12:39:02 »

Trestní oznámení na neznámého pachatele mi přijde jako poměrně vhodné.
Byť tím řekněme nezpůsobují finanční újmu přímo Vám, ale Vašim zákazníkům... tzn. přestože újma Vám je spíš v rovině poškození dobrého jména. Zločinný úmysl (tzn. minimálně stádium pokusu) jasně plyne z napodobení Vašeho oficiálního webu, zneužití identity editora apod. Trestní oznámení nemusí podávat zrovna poškozený (pokud mu to nestojí za to) ale prakticky kdokoli, kdo se o trestném činu dozvěděl. Svým zákazníkům tím naopak prokážete službu, nenecháte je ve štychu.
Otázka je, zda budou poškození zákazníci ochotni o trestném činu alespoň svědčit :-) ale to je asi vedlejší.

Naše policie má nástroje pro mezinárodní spolupráci a takových případů je nenulové množství. Policie má taky možnost, s jasně danými podmínkami a záznamem o přístupech, nahlížet do neveřejných částí různých rejstříků apod. Neslibuji, že z Vás budou nadšení, ale ujišťuji Vás, že nebudete rozhodně první, kdo požádá o pomoc. Podvodníčků tohoto typu a různé úrovně sofistikovanosti je poměrně hodně. Pravděpodobně nejste jediná oběť daného "šikuly" = připojíte se třeba ke spisu, který už je otevřený. Co jsem slyšel, často se poškozených postupně nasbírá větší počet. PČR v tomto rozhodně není neschopná nebo něco v tom smyslu - spíš je takových malých podvodníčků tolik, že je rutinní řešení téhle chamradi trochu sisyfovská práce.
Pokud přijde místnímu providerovi na Ukrajině nebo registrátorovi v USA od jejich místní police předvolání k podání vysvětlení, nebo výzva ke spolupráci a nápravě, tak to má kapku větší váhu, než Vaše emailová stížnost na abuse@provider.ua. A nakonec... pokud se dotyčný podvodný web a celé to schéma soustředí v zásadě na tuzemský okruh potenciálních obětí, dost možná je útočníkem taky někdo odsud, a s trochou štěstí je dohledatelný = následně postižitelný našimi orgány na našem území.

524

Sítě / Re:Sháním 100Mbit/s ethernet HUB (opravdu HUB, ne switch)

« kdy: 03. 03. 2021, 20:54:22 »

Per-VLAN FDB jako opatření proti duplicitním MAC adresám ve více VLANách je finta možná nepříliš známá, dokud se nedostanete do situace, kdy je přesně tohle Váš problém :-) Nedávno jsme o tom tady na rootu akademicky podebatovali... a popravdě nevím, jak se ke shodným MAC adresám na dvou různých IP/Eth rozhraních bude chovat ARP v nějakém Linuxu - nechci a priori tvrdit, že zrovna pro ARP a jeho tabulku to představuje problém, dost možná nikoli. BTW doporučuji terminologicky rozlišovat switch na druhé vrstvě a jeho CAM=FDB tabulku vs. router na třetí vrstvě a jeho ARP tabulku pro překlad IP adres na adresy druhé vrstvy. Heh dovedu si představit, že v "L3 switchi" (router on a stick trčící z VLANového switche) bude problém nikoli v ARPu, ale spíše ve druhé vrstvě, pokud CAM=FDB tabulka není per VLAN, takže shodné MAC adresy ve dvou různých VLANách ve FDB kolidují, čímž si navzájem podrážejí nohy... což lze pod dojmem chování IP a vyšších vrstev na první pohled dezinterpretovat jako zádrhel v ARPu :-)

525

Sítě / Re:Sháním 100Mbit/s ethernet HUB (opravdu HUB, ne switch)

« kdy: 02. 03. 2021, 15:43:28 »

Zkuste prozkoumat tohle, jsou tam i obrazky s HW upravami
https://github.com/libc0607/Realtek_switch_hacking

Cinstinou nevladnu, nicmene jak koukam na ty dumpy firmware mgmt switchu mne napadlo, netusite nekdo u realteku jak to je uvnitr s temi lowcost switch IC ? Tipnul bych si, ze tam bude integrovany nejaky microcontroller, ze to nemaji cele pomoci automatu.

Co si matně vybavuju, a teď jsem se namátkou mrknul (viz odkazy níže), tak ty low-endové matice žádné MCU jádro neobsahují. Umí běhat buď autonomně (hloupý switch), nebo spřažené s externím CPU/MCU (managed).

Odhadem i v režimu "hloupý switch" to chce aspoň maličkou sériovou konfigurační EEPROM.

Management by teoreticky snad šel zařídit i bez vlastního L2/L3 rozhraní (pouze přes MDIO nebo I2C) ale reálně to tak nebývá, reálně management CPU mívá interní propoj do switchovací matice pomocí MII - kde switch se tváří jako MII PHY, zároveň ale přes MDIO budou patrně vidět všechna jednotlivá PHY per port pokud se nepletu. Potažmo tento interní propoj může být VLAN-tagovaný tzn. sloužit jako trunk pro routování mezi VLANami apod. V jednom datasheetu jsem zahlédl, že switchovací matice umí pomocí custom tagu předat CPU informaci, skrz který vnější L2 port paket přišel...
Jinak MII rozhraní na switchovací matici (čipu) bývá možno použít také "v roli MAC" a připojit na něj externí PHY (transceiver) = implementovat další externí port, třeba optický uplink apod.

http://realtek.info/pdf/rtl8306sd%28m%29_datasheet_1.1.pdf

http://realtek.info/pdf/RTL8318P_1-1.pdf

https://www.marvell.com/content/dam/marvell/en/public-collateral/switching/marvell-switching-link-street-88e618x-product-brief-2005-04.pdf