Příspěvky

301

Sítě / Re:Vysílací výkon a pásmo na MikroTiku

« kdy: 29. 06. 2022, 23:12:21 »

O.K to je přesnější informace.
Jen taková hloupá připomínka, protože se mi to už stalo - zkus snížit vysílací výkon, třeba na 1-5 dB. Zažil jsem případ, kdy se k routeru ve stejné místnosti nedalo připojit (? silný signál ?), ale na chodníku před domem se k té samé wifině dalo bez problémů připojit...  a Ty máš Mikrotika s označením High Power.
...

Mám podobný zážitek: dva mikrotiky proti sobě, antény malé parabolky tuším asi 24 dBi, na vzdálenost pár desítek metrů, s defaultním (plným) výkonem ukazovala rádia RX level snad -40 dB a nechtělo se tomu. Po snížení vysílacího výkonu o 10 dB se spoj najednou rojel jako víno.

302

Sítě / Re:Vysílací výkon a pásmo na MikroTiku

« kdy: 26. 06. 2022, 22:00:08 »

Chcete-li být ohleduplný, tak to ufo namiřte mírně k zemi. Ona ta plochá anténa bude mít odhadem relativně široký hlavní vyzařovací lalok... a pokud nemáte moc velký prostor, který chcete ozářit, a chcete být slušňák, tak omezte výkon. Dolaďte podle praktického pozorování, jak Vám chodí klienti.

Našel jsem zmínky, že v indoorové části 5GHz pásma funguje radarové snímkování zemského povrchu z družic. Tzn. nejedná se zde o problém s pozemními meteo-radary - ty jsou na kanálech 126 a 128 (někdo říká 127 a 129, pokud uvažujeme 5MHz rastr). Tady o tom něco píše Jenda, tady je seznam kanálů. Dovolím si vyslovit domněnku, že k zarušení meteo-radarů je potřeba notná dávka úsilí: vysoký výkon a/nebo být blízko a/nebo namířit ostře směrovou anténu přímo na radar... soudě podle těch úrovní, které ČHMÚ udává. Plus samozřejmě trefit kanál. Takže pokud si na zahrádce v ďolíku zdvořile osvítíte kolečko trávníku indoorovým kanálem, rádiem které výkonově nevybočuje z mantinelů, zcela určitě si Vás nevšimnou meteoradary a nejspíš ani ty družice. A neměl byste ani šlápnout na kuří oko místním WISPům, protože teoreticky by indoorové kanály neměli venku používat. Nabízí se ještě možnost, umístit nad rádio plechový "přístřešek" (kšilt) proti dešti, funkční také jako "límec" proti vyzařování vzhůru k nebi - ale tady pozor, hrají roli přesné rozměry, aby límec naopak nefungoval jako direktor :-) Sám to spočítat nedokážu.

Ehh... je to ilegální, jako provozovatel nesete zodpovědnost, ale když nebudete dělat bordel v éteru, tak by to snad mohlo projít.

Dějou se tu horší zvěrstva. Repeatery signálů mobilních sítí, jejichž autokonfigurace zisku pracuje na principu periodického zavazbení a následného dočasného snížení zisku...

303

Sítě / Re:Přístup do místní sítě přes OpenVPN

« kdy: 26. 06. 2022, 21:17:59 »

Route v .OVPN souboru pro klienta mi připadá správně.

Ručně přidaný statický route v routeru je blbě, bude duplicitní a mohl by dělat neplechu - správně Jenda říká, že znamená de facto smyčku. Těžko říct, jak si firmware routeru přebere, že má cosi routovat na své vlastní lokální rozhraní - mně to smysl nedává :-) Cílem routu má být vždycky nějaká sousední mašina (IP adresa), na kterou "tento router" přímo vidí přes L2 médium. Počítám, že na routeru nemáte přístup do shellu - ale zkuste pohledat, jestli by někde ve webovém rozhraní nešla vypsat aktuální routovací tabulka z kernelu. Měly by tam být od přírody/automaticky subnety, kterými máte očíslovaná rozhraní. Tzn. ten 192.168.1.0/24 by tam už měl být, netřeba ho přidávat, router o něm ví. Ten subnet je totiž tzv. "directly connected", tzn odpovídající route není třeba předávat další gatewayi, provoz jemu určený se prostě odešle příslušným rozhraním (jenom se ARPem překládají IP adresy na MAC adresy přímo viditelné na L2).

Ping je jedna věc.
Na routeru si bohužel tcpdump zřejmě nepustíte.
Ale mohl byste z klienta zkusit poslat traceroute - pod Windows tracert.
Mimochodem, co máte na klientu za operační systém? Většina OS má v příkazovém řádku příkaz "route", kterým lze přinejmenším ověřit, jestli se po připojení tunelu objeví route specifikovaný v .OVPN souboru.

Pokud se provoz nerozjede ani po odstranění toho chybně přidaného routovacího záznamu na routeru, stálo by za prověření, jestli do toho nekecá firewall na "počítači v LAN", ke kterému se snažíte vzdáleně dobouchat. Tady by pomohl wireshark na dotyčném počítači v LAN, protože ten má odposlechovou sondu před firewallem (co nejblíž fyzickému rozhraní).

A pak je ještě možné, že forwarding z toho tunelu není automaticky povolen ve firewallových pravidlech na routeru... (jak psal Jenda. Že by na routeru byl paušálně vypnutý /proc/sys/net/ipv4/ip_forward, tomu z principu nevěřím.) Mít přístup do shellu, navrhl bych tcpdump, iptables -L apod. Leč, firmware je zapečený proprietární... Zlaté OpenWRT.

304

Distribuce / Re:Identifikace ovladače v Debianu

« kdy: 26. 06. 2022, 10:39:06 »

@Jenda : uvědomil jsem si, že jsem dal do placu nějaké svoje doporučení jako dogma, přitom to souvisí s mými specifickými potřebami, převážně v práci. Vaše potřeby jsou nejspíš jiné.

Když hledám důvod nějakého divného chování něčeho v servisu, málokdy využiju dva kanály, ale potřebuju šířku pásma. Koukám na přechodové děje, "když někdo cvakne vypínačem". Nebo třeba hledám nějaké rušení, a využiju, pokud skop umí ukázat FFT. Taky mám generátor krátkých ostrých pulzů, který ve spojení se skopem používám jako reflektometr (TDR) při hledání vaklů v koaxových konektorech. Obecně jsem mírně cáklej rádiem. Na RS485 nebo porovnání dvou hran 1PPS mi přesně stačí dva kanály proti společné zemi, v krajním případě plus externí trigger (vlastně třetí vstup).

Soudě podle Vaší volby : čtyřkanál, "pouhých" 50 MHz analogově, ale 1GSps, a zřejmě 6 nebo 12M bodů na kanál, plus ty odposlechové sondy co zmiňujete... řekl bych, že si hrajete s MCUčky, sběrničkami, GPIO a tak :-) a prostě volíte přístroj podle svých potřeb.

Koukám, že konkrétně Vámi zmíněný Rigol DS1054Z je ten slavný levný model, co se dá "softwarově upgradovat" o jednotlivé fičurky. Šířka pásma až 100 MHz, analýza sériové komunikace...

Ze sortimentu levných skopů mám takový pocit, že se ceny nehýbou už asi 10 let. Dvoukanály s 2 GSps končí kolem 20-30 kKč. Vývoj jakoby se zastavil - u velké čínské trojky, a třeba i u slovenského ETC, od kterého mám v práci M595. Chvíli jsem si potěžkal v ruce OWON SDS8202V (jeho zajímavostí je za příplatek bateriové napájení) takže mám trochu srovnání. Pravda je, že konkrétně u OWONu vidím novou řadu XDS4000, která končí čtyřkanálem 5 GSps / 500 MHz v ceně asi 5000 USD. Tzn. inovace probíhá, šířka pásma roste, ale cena jde nahoru - směrem ke značkovým západním strojům. Pozoruji vývoj i v související součástkové základně (křemík - rychlé ADC a analogové zesilovače). Bohužel i tady to spíš vypadá, že vývoj pomalu brzdí. Mooreův zákon se zadýchal - novější součástky jsou rychlejší jenom za cenu nižšího rozkmitu zpracovaných úrovní napětí, mají nižší napájecí napětí. "Ospalou atmosféru" v sortimentu osciloskopů si vysvětluji taky tak, že na těch gigahertzích už dávno nefungují klasické sondy se "zemním krokodýlem na vodítku" a je vůbec problém, navázat skop do měřeného zařízení, aniž by člověk narušil funkci pozorovaného obvodu, rozměrově je to všecko mrňavé apod. Prostě tyhle frekvence už jsou pro zatvrzelé feinschmeckery, kteří vědí co dělají, bez přístroje této kategorie se neobejdou a nemají problém, utratit 1000 EURO za aktivní sondu, vyrábět si na míru speciální sondy / vazebné přípravky apod. (např. kartu do PCI-e slotu s impedančně a konektorově přizpůsobeným výstupem pro osciloskop). Pro klasické rádio v těchto pásmech je beztak už hodnotnějším vybavením čistokrevný spektrální analyzátor, nebo FDR, nebo vektorový analyzátor sítě - přesný průběh vlny v časové doméně nikoho moc nezajímá.

305

Sítě / Re:Vysílací výkon a pásmo na MikroTiku

« kdy: 26. 06. 2022, 09:27:43 »

@Ja.: zdvořile děkuji za podrobnou odpověď a za sdělenou zkušenost.

Pamatuji si i nějaké dřívější sporadické pokusy, ale je to asi rok-dva zpátky, co jsem to soustředěně řešil. Testoval jsem několika různě starými noťasy a telefony s nakousnutým ovocem - a v různých kombinacích ještě s pásmem apod. se asociace klienta na AP zdařila či nezdařila. Nenamáhal jsem se, čenichat u toho kismetem/wiresharkem nebo tak něco... ono na WPA2 toho člověk ze vzduchu ani moc neodposlechne. A bohužel nějaký debug na jabku taky moc není (zejm. na telefonech). Na dnešních klientských OS člověk většinou jen tak tak rozliší, že má blbě heslo do WPA2, vs. že se krypto úspěšně navázalo, ale že z nějakého důvodu klient nedostal odpověď od DHCP, nebo nedejbože něco mezi tím.
Co jsem se tehdy dogooglil, lidi s kombinací jabko+mikrotik řešili jak na AP nastavit preambuli (tuším nejpřítulnější nastavení je "long and short", ale zkoušel jsem i jiné možnosti) a daly se najít všelijaké historické rady z konkrétních starších verzí JabkoOS vs RouterOS, jak šel vývoj... Šířku kanálu mám 20 MHz na 2.4 GHz a 40 MHz na 5 GHz, ve standardním rastru a řídící kanál je tuším standardně ten spodní (všiml jsem si nějaké fajfky, kde se toto dá nestandardně změnit). V tomto bych problém nečekal. A pár dalších fajfek, co jsem zkoušel zapnout vypnout... management frame protection, už si nepamatuju co dál.

Jestli mám na RouterOS něco rád, tak přesně tu relativní otevřenost a bohatství laditelných fičurek = možnost "svobodně se střelit do nohy", když se v tom hrabu jak neinformovaná opice.

Bohužel tady se potkaly dvě různé "trochu svoje" implementace WiFi stacku. Problémy v této rovině vídám v průběhu let ve velmi různých technologiích: Ethernet, PCI-e, SCSI/SATA, ACPI... Všichni testují jenom proti referenční/kanonické implementaci, což bývá nejsilnější hráč na trhu. Navzájem proti sobě pak "menšinoví hráči" vykazují různé quirky...

306

Sítě / Re:Vysílací výkon a pásmo na MikroTiku

« kdy: 25. 06. 2022, 23:01:26 »

Nezkusíte OpenWRT ?

Největší výhodou MikroTiků je právě RouterOS, proč by tam někdo proboha cpal něco jiného? To už je lepší si na OpenWRT koupit za tři stovky TP-Link, ten bude dost možná mít i silnější HW.

Toto celé jsem si prošel :-)

Taky mám rád RouterOS - pokud třeba potřebuju bezdrátem propojit dva segmenty metalické LAN. Ale když jsem ho zkusil nasadit jako indoor wifinu ve firmě, tak se mi některá jabka nechtěla chytit - a hádejte, kdo má u nás jablečné telefony a počítače. Inu šéfové. A návštěvy. Vzájemná antipatie RouterOS a jablíček údajně souvisí s codebase WiFi ovladačů, která je u Mikrotiku údajně dost "svoje".

TP-link měl tak před dvěma lety výběr hardwaru s čipsety Qualcomm/Atheros a dostatkem RAM a Flash - spousta výborného hardwaru pro OpenWRT. Ale pak celý sortiment vykuchali a ořezali, takže na nových modelech OpenWRT nechodí.

Naproti tomu Mikrotik má zřejmě citelně delší produktovou životnost jednotlivých modelů Routerboardů. "Průmyslový" životní cyklus. Tzn. podle mého je to už v tomto ohledu pro OpenWRT citelně lepší hardware, než nějaký SoHo TP-link, který za měsíc nepůjde koupit (tj. vlastně už se stalo).

Zmíněný RBSXTsqG-5acD má podporu v posledních releasech OpenWRT a je založený na platformě Qualcomm/Atheros IPQ4018, která obsahuje čtyřjádrový ARM. To není slabé železo :-) Chce to jenom doinstalovat a odšpuntovat irqbalance démonka. Během posledních pár měsíců jsem si zprovoznil OpenWRT na cAP AC a na hAP AC2, ty mají stejnou platformu.

307

Sítě / Re:Přístup do místní sítě přes OpenVPN

« kdy: 25. 06. 2022, 22:45:58 »

Souhlas s Jednou, je potřeba na OpenVPN klientovi přidat routu do tunelu, aby věděl, kudy z dálky do té kýžené LANky.

Věcná poznámka na okraj: vedle "device tun" (IPv4) umí OpenVPN taky "device tap" (emuluje/enkapsuluje L2 Ethernet). Takže se teoreticky nabízí možnost, rozjet "device tap" a soft-bridgem přišít tunel do interní LANky. Toto řešení ale nedoporučuji. V LANce může běhat dost všelijakého broadcastového/multicastového smetí, a všechen ten bordel byste si posílal skrz relativně "tenkou" linku (VPN tunýlek) někam na dálku domů... Forwarding na 3.vrstvě Vás efektivně zbaví všelijaké neplechy, která se odehrává v rámci L2 sítě.

308

Sítě / Re:Vysílací výkon a pásmo na MikroTiku

« kdy: 25. 06. 2022, 14:27:43 »

Nechce povolit indoorové frekvence? Žeby omezení outdoorového APčka? Bohulibé, dané normou, nebo spíš obchodní?

Nezkusíte OpenWRT ? Pokud mohu soudit: relativní svoboda konfigurace, a bezproblémový provoz s "jablíčky" různých verzí a věků (na rozdíl od RouterOS). OpenWRT by mělo jít vyzkoušet i nanečisto - bootnete přes DHCP+TFTP image "initramfs+kernel". Akorát nevím jistě, jestli je v tomhle imagi i LuCi a kompletní wireless. Snad ano.
K testu OpenWRT potřebujete DHCP server. Možná radši aby uměl i bootp. Pro mě asi nejsložitější bylo vyškádlit Mikrotika k bootu z DHCP/bootp. V případě zájmu mohu navést dál.

309

Distribuce / Re:Identifikace ovladače v Debianu

« kdy: 25. 06. 2022, 07:32:09 »

@Jenda naprostý souhlas. Bohužel musím říct, že dokud jsem neměl skop, tak jsem neměl představu, co je na té sběrnici blbě *tentokrát*. A je poněkud nefér, že mně můj skop koupil před lety zaměstnavatel, takže to nešlo z mé kapsy. Ale v dnešní době bych si snad nějaký koupil i ze svého, na takové to domácí kutění... nějaký ten OWON/Rigol/Hantec... Dvoukanál a čím víc GSps tím líp. Pak ještě chvíli trvá, než si člověk uvědomí, na co to vlastně kouká, a na co by koukat měl, kam zakousnout krokodýla pro referenční zem atd. To je ale na tom celém hezké - člověk se učí s novou hračkou a trochu se při tom dovzdělá...

Pokud se týče RS485, je osciloskop důležitým nástrojem v konkrétním bodě "diagnostického postupu". Připadám si, že bez něj jenom akademicky teoretizuju. A pak připojím sondu a prostě vidím.

A taky, USB/485 dongly není od věci mít dva-tři. Aby mohl být jeden na komunikaci a druhý na odposlech, nebo na duplexní odposlech RS422 (čtyřdrátu), nebo na porovnání dvou kusů, jestli jeden nemá drbnutý transceiver.

310

Hardware / Re:Chlazení domácího racku

« kdy: 24. 06. 2022, 14:33:31 »

...A to vkusně umístěné APčko...

A to, že ta plechová bedna vytváří umělou zem a mění šíření elmag. vln z antén, vám nevadí?

Život je jeden velkej kompromis :-)

Ano ten reflektor nad APčkem nějak ovlivní vyzařovací diagram a PSV anténních zářičů. Stejně širokopásmová/vícepásmová anténa neladí pořádně ani v jednom pásmu, a PSV to bude mít všelijaké (rozkolísané). Vyzařovací diagram taky všelijak šilhá podle přesné frekvence (napříč pásmem). Stačí si chvíli pohrát se sitemasterem a prutovou anténkou - záleží jak daleko od antény chytíte kabel, nebo přiblížíte ruku, a hned to má na napájecím portu jinou impedanci... chuj s tim. Ona si příroda nějak pomůže. Když se to rádio bude trochu slušně chladit, prospěju jeho životnosti víc, než když budu řešit nějaký nepůvodní nedaleký reflektor...

311

Distribuce / Re:Identifikace ovladače v Debianu

« kdy: 24. 06. 2022, 11:45:20 »

u toho bazmeku co mám píšou, že je přímo RS485 a i vývody má označený jako A, B a ne RX, TX.

Já bych řekl, že Váš USB/485 dongle má automatické HW přepínání RX/TX vyřešeno = vytaženo z UARTu.
Schéma plošáku donglu bude zřejmě velmi podobné referenčnímu, viz str.16 v datasheetu (kapitola 7.6.). Vaší pozornosti doporučuji výstup CH341 zvaný TNOW. Tenhle výstup je odhadem trvale přítomen a aktivní = netřeba ho explicitně konfigurovat v registrech UARTu (nebo řešit v ovladači, nebo mít uložený v I2C EEPROM).

312

Hardware / Re:Chlazení domácího racku

« kdy: 23. 06. 2022, 10:58:31 »

@Molex1 hezká čistá práce ten rack. A to vkusně umístěné APčko... respect. Dokonce lopatky ventilátoru ladí s barvou krytek RJ45. A to symetrické aranžmá... tomu ty skleněné dveře vyloženě sluší.
Za připravené otvory pro ventilátory palec nahoru výrobci racku - nemám představu, zda je to v dnešní době standard :-)

Jinak "přetlaková" ventilace je standard v průmyslových PCčkách: ventilátor na vstupu co fouká dovnitř, v utěsněném sání ventilátoru vsazený filtr proti hrubému vláknitému prachu. Ten filtr mívá malou plochu (stejný formát jako ventilátor) a výrobce to dohání silným hlučným ventilátorem. Kdybych toto chtěl doma, snažil bych se o velkou plochu filtru a ventilátor s nízkými otáčkami... 200gramový vatelín stojí asi stovku za běžný metr (šíře 150cm). Není to sice echt filtrační materiál, ale lepší než drátem do oka určitě bude.

313

Hardware / Re:Chlazení domácího racku

« kdy: 23. 06. 2022, 09:02:44 »

Máte představu, jakou reálnou spotřebu = topný výkon ten rack momentálně má?

A... jak vypadá momentální ventilace? Úplná nula, nebo jsou tam aspoň nějaké průduchy?

Pokud nula nebo téměř nula, pravděpodobně by stačilo, zajistit určitou výměnu vnitřního vzduchu s okolím. Má rack nějaká demontovatelná víčka na připravených okénkách pro kabelové prostupy apod.? Případně, umíte vzít do ruky flexu? Rack je stejně jenom kovová skříň, na tom není v záruce co reklamovat...

Ohledně "USB na PWM": viděl bych problém v tom, že standardní USB port umí dodat asi 2.5W. To je dost málo i na jeden ventiláítor o výkonu větším než "naschvál hodně nízkém". Na druhou stranu, mám tady na dílně takové udělátko na příležitostné ad hoc přichlazování "vrabčího hnízda na stole": ventilátor 120x120x25mm, na 12V a už původně spíš nízkootáčkový, a tento jsem natvrdo přiletoval na +5V z USB (uřízlý ocásek od staré myši nebo tak něco). Je schopen na 5V nastartovat, hezky pomalu se točí a "tak trochu hýbe vzduchem".

Zatím neznám počáteční stav spotřeby a chlazení, ale třeba by pomohlo, vyrobit do racku dvě okénka, do toho horního vsadit 120mm podtočený ventilátor, a pokud nechcete, aby stroj fungoval jako "labyrintový lapač prachu", zkuste na spodní otvor pohodit kus vatelínu. Čím větší plocha filtru, tím menší bude klást odpor a tím déle bude trvat, než se zanese.

Anebo jenom demontovat sajtny.

314

Distribuce / Re:Identifikace ovladače v Debianu

« kdy: 20. 06. 2022, 22:14:38 »

...dovolím si poznamenat, že než se peklovat ručně s nějakým přepínáním RX+TX, je citelně jednodušší, pořídit si modul, kde UART přímo řídí half-duplexní transceiver interním flagem "TSRE" resp. "TEMT". Tzn. pokud má UART neprázdný výstupní shift registr, tak je transceiver ve stavu "TX", jinak je ve stavu "RX" (budič přepnutý do stavu vysoké impedance a přijímač naslouchá). Z hlediska programátorského opracování, prostě pošlete znak nebo řetězec znaků a o víc se nestaráte. Co jste předal do kaskády bufferů (která končí v UARTu FIFO a posuvným registrem) to se přesně odvysílá.

Zrovna značku WinChipHead nemám úplně rád, kdysi mě naštvali nepovedeným konvertorem USB/LPT.

Na USB bych si dovolil doporučit něco od FTDI, lépe originál, ale jsou k vidění i čínské pajcy - které ovšem nemusí fungovat s originálními ovladači od FTDI pro Windows, ale open-source ovladač v Linuxu by je měl vzít bez problému.
jeden druhý třetí čtvrtý.

Ve směru RX mají moderní UARTy veliké FIFO, klidně 64-128 B, a následuje driver obsluhující interrupt... tam se data taky neztratí.

V user space prostě pošlete dotaz a pověsíte se na otevřený "deskriptor" a čekáte co přijde jako odpověď. Nějaké časování znaků není potřeba řešit.

USB serial nemá USB třídu - vlastně má, CDC ACM (modem), ale tu většina USB/serial donglů nepoužívá. Většina USB/serial donglů (UARTů) má na USB proprietární rozhraní. Linux k tomu přistoupil tak, že má cosi co vypadá navenek jako "class-based ovladač pro USB serial". Asi to tak nemají všechna distra, ale ovladač usbserial jsem vídal zkompilovaný jako modul, ovšem s monoliticky zakompilovanými ovladači pro běžné modely/značky USB/serial čipů. Takže jsem býval zvyklý loadnout "usbserial" a bylo vyřešeno. Skutečně populárních je asi 5 značek USB/serial čipů.

A dál záleží, v čem je napsaný ten Modbus. Provozovat ho v Pythonu... no asi proč ne :-) Rozhodně může Modbus žít v user space, sám jsem kdysi na to napsal v Céčku rozvlákněnou knihovnu, bohužel jsem nedostal svolení ji vystavit k volnému downloadu...

BTW tyjo, RTL8821 má USB variantu? Já ho znám jako poměrně solidní a úspornou ACčkovou wifinu na (Mini)PCI-e.

315

Hardware / Re:Jak na upgrade firmwaru (BIOSu)

« kdy: 16. 06. 2022, 08:58:21 »

Nebo pouzit nastroj k tomu urceny:
http://azin.cwcodes.net/

Hezky, ten jsem neznal, dík :-)
Zdálky to vypadá jako embedded studio za starých časů, kdy se Windows Embedded ještě skládaly na míru offline z drobných součástek.

Než to vyzkouším, budu se muset rozmyslet, nakolik tomu důvěřuju - v rovině bezpečnostního cirkusu. Na můj vkus to není zrovna open, na první pohled.