Témata

1

Sítě / Modem 3G+4G se na čisté 4G nechce zavěsit

« kdy: 22. 11. 2022, 17:21:28 »

Vážení kolegové debatéři,

lámu si hlavu s jednou záhadou v placeném datovém éteru.
Samozřejmě jsem zkusil zaprudit u výrobců modemů a taky (nepřímo) u mobilního operátora, ale poněkud bez výsledku. Nějaké tipy jsem dostal, ale problém vyřešen není a schází mi možnost nějak ladit komunikaci MT se sítí operátora. V poslední instanci zkouším nesměle lovit tady veřejně, zda by někdo nevěděl...

Disclaimer, hrozně nerad bych se někoho dotkl: zcela chápu, že lidé zdatní a znalí jsou vzácní i na straně mobilních operátorů, a jestli se něco vyvažuje zlatem, je to jejich čas. Mají na krku hordu standardních telefonních zákazníků, plus rostoucí skupinu "připojených počítačů" apod., a celá ta záplava mobilních zařízení generuje vzorce provozu, které třeba nejsou nepodobny DoS útoku na vzácné zdroje mobilní sítě apod. Takže nezbývá mnoho času a elánu, řešit první vlaštovku, která věští nějakou okrajovou nekompatibilitu. Popravdě nechci příliš kvantifikovat, nakolik je ten problém hromadný a "slibný" do budoucna - třeba se k nějaké představě dopracujeme.

Blíže technicky k věci:

Řeším zas po nějaké době jakési "WWAN modemy". Takové ty krabičky, co kdysi mívaly jenom sériový port, na něm Hayes-compatible AT příkazy, poměrně záhy jim k 2G CSD přibyla schopnost 2G GPRS (jakožto první paketová mobilní síť). Dále se vývoj ubíral postupným přidáváním 3G, 4G, nejnověji 5G - kolmo k RAN technologiím přibývala podporovaná pásma. Od původního sériového portu jsme se dostali k USB 2.0 (a na obzoru je USB3 a PCI-e). Co do mechanického provedení jsem dříve potkával hlavně externí krabičky, později "vestavbový" formát MiniPCI-e, nově M.2 (NGFF). Dlouhá léta mi procházely rukama převážně modemy zn. Sierra, vzácně něco jiného... (Huawei, Telit, Siemens) ovšem v posledních několika letech se mým osobním favoritem stala značka Quectel, konkrétně jejich moduly EC25E (2G/3G/4G a skoro všechna naše pásma).

Všimněte si, že u nás už všichni tři operátoři zhasli 3G = UTRAN. Já to zjistil až minulý týden, pohledem do éteru - ale údajně je tahle novinka stará už asi půl roku.

Momentálně dumám nad dvěma modemy ve formátu M.2. Jedná se o modely Sierra EM7455 a konkurenční Quectel EM05EFA. Na první pohled společným jmenovatelem je, že oba modemy shodně umí 3G a 4G, a shodně NEpodporují 2G. Prostě E-UTRA ano, UTRAN ano, ale GERAN už ne - RIP GSM+GPRS+EDGE.

Problém nastává se SIMkou jednoho tradičního tuzemského operátora. Oba modemy se chovají stejně: modem najde SIM kartu, následně "vyhledává síť", případně skončí ve stavu "registrace odmítnuta".

Kód: [Vybrat]

AT+CPIN?
+CPIN: READY

OK

at+creg?
+CREG: 0,2

OK
Konkrétně jsem u AT+CREG viděl tyto result kódy:
+CREG 0,2 = vyhledává síť
+CREG 0,3 = registrace odmítnuta/selhala

Základní AT+CREG znamená, zda se MT podařilo navázat minimální prvotní kontakt se sítí operátora. Normální telefon je schopen v tomto stavu posílat SMS a navazovat hovory (hlasové nebo CSD).

Teprve v dalších krocích případně dochází k navazování "paketové" komunikace: registraci k paketovým službám lze ověřit příkazem AT+CGREG (registrace ke "GPRS"), a teprve poté (se objeví rákosníček) lze případně "navázat PDP kontext", a využít ho skrz jedno z potenciálně několika rozhraní, kterými modem k tomuto účelu oplývá (emulace PPP, nebo nějaká ta "nativní WWAN síťovka na USB" v jednom z asi čtyř obvyklých formátů).

Chci říct, že i pokud by "pro SIM kartu nebyly povoleny datové služby", základní registrace k RAN by se každopádně zdařit měla (kýžený stav: +CREG: 0,1). Ovšem u kýženého operátora tato selže. Prostě síť s tím modemem (nebo SIMkou?) nechce nic mít.

Problém jsem původně zaznamenal se Sierrou, následně reprodukoval na Quectel EM05EFA. Nakonec jsem ho reprodukoval i s EC25E MiniPCI-e, pokud jsem mu v konfiguraci zakázal 2G RAN.

Přitom ale oba zmíněné M.2 modemy (bez podpory 2G) se s odpovídající SIMkou bez problému regnou ke konkurenčnímu operátorovi (s matkou v Německu), tzn. chytí se přímo jeho 4G = E-UTRA RAN, a taky datové služby se následně bez problému rozběhnou.

A již zmíněný EC25E MiniPCI-e, pokud mu nechám povolené taky 2G (+3G+4G), tak se v něm SIMka kýženého tuzemského operátora normálně chytí. Tuším se mi i podařilo pozorovat, že se chytí napřed 2G GERAN, ale následně přeskočí na 4G E-UTRA. A datové služby fungují, tzn. jsou povolené. Tzn. touto cestou to jde.

Zkusil jsem pro zábavu taky starou Sierru MC8092 = 2G+3G. Ta se chytla spokojeně 2G, a datové služby jely EDGE.

Pokud si správně pamatuji, někdy začátkem léta nám Sierra EM7455 u "kýženého operátora" ještě fungovala. Je možné, že v té době ještě svítilo 3G.

V určité fázi testování ve mně taky hrklo, jestli nemám jenom starý známý banální problém s kvalitou/sílou signálu. Jako že síť ve městě poňouká klienty, aby se přihlašovali na "městská" vysoká pásma 1800 a 2100 MHz. Takže jsem si dal záležet, abych měl ověřenou (known-good) anténku na krátkém kabelu venku z okna. Prakticky jenom na pigtailu U.FL resp. MHF4 na SMA (venku z okna byl celý modem v USB redukci). Modemy Quectel jsou schopny nahlásit, co vidí ve vzduchu a jak silný je ten signál, a následně jim mohu říct (v mém případě) ať se drží Bandu 20 (800 MHz), který tu má nejsilnější signál, a od kterého síť operátora své klienty obvykle odrazuje, pokud ji nepřehlasujete. Nic z toho nepřekoná popisovaný problém s registrací "přímo na 4G" u kýženého operátora.
Naopak pokud použiju modem, který umí i 2G, tak se registrace 2G->4G povede a data tečou, ať už mám anténu kdekoli (na stole v paneláku za pokovenými okny a žaluziemi) - tzn. prakticky to rádio funguje i "na vařené nudli", pokud má pěšinku k registraci věcně v pořádku.

Ještě mi poradili, abych pomocí AT+CRSM získal ze SIM karty seznamy HPLMN, OPLMN, UPLMN a FPLMN. Získal jsem, dekódoval, nevidím tam žádný problém. SIM karta "kýženého operátora" má správně Home PLMN, Operator-controlled PLMN selector obsahuje jenom zahraniční roamingové partnery, atribut/"soubor" UPLMN není přítomen a FPLMN obsahuje místní konkurenci. Všechno jak má být, a všechno analogicky se SIMkou od konkurenta.

Podle mého to všechno znamená, že síť kýženého operátora vyžaduje, aby se MT chytil napřed 2G (nebo 3G, které mezitím už neexistuje), než je MT připuštěn k registraci do 4G RAN.
Nebo je problém v nějakém dalším aspektu, který je společný oběma zlobícím M.2 modemům. (Něco ve společném základu firmwaru od Qualcommu?)

Bohužel, pokud mohu soudit, paleta trvale dostupných modemů ve formátu M.2 není zrovna široká - takže nějak nemám po ruce M.2 modem od ještě dalšího výrobce, nebo jiný model v tomto formátu s podporou 2G. Určitě jsou tu vedle Sierry a Quectelu i další značky, ale nejsou trvale dostupné "lusknutím prstů". Kromě toho si troufnu rejpnout, že trend "vynechat podporu 2G" s příchodem nových 5G-capable modemů nejspíš ještě zesílí. No... uvidíme.

"Změnit operátora" taky nemusí být cesta nejmenšího odporu, pokud máte flotilu vozítek, kde jezdí směs různých modemů staršího data dodání v exotických formátech, a třeba jste už jednou z podobných důvodů operátora vyměnili...

Uvítám jakoukoli reakci. Vlídné slovo, technický tip, nakonec i fundovaný odsudek člověka kamsi posune :-)
Děkuji za pozornost.

2

Software / Ukládání souborů ve firmě, koncepčně: jak strukturovat adresářové hierarchie?

« kdy: 30. 06. 2022, 12:14:43 »

Lidičky, odpusťte mi.  Asi se nudím, nebo je to příznak blížícího se mentálního důchodu... ale zamýšlím se nad takovou napohled primitivní a povrchní otázkou. Odtud toto téma.

Ukládání věcí ve firmě do souborů. Jak v tom udělat nějaký pořádek. Třeba nedokonalý, ale systém.
Asi se tím zhruba zabývá obor "document management" - možná komplet, možná zase jenom nějakou fasetou. Nepochybuju, že jsou na trhu softwarové produkty, které se snaží tvářit, že Vám to jednou provždy "vyřeší".

Jasně, máme provozní systém (účto nebo ERP nebo tak něco, podle toho jak je firma velká). Do kterého patří nějaké věci. Kromě toho v organizaci putují různé další soubory. Něco člověk stáhne z netu a je to pro něj užitečné a chce si to nechat (a do databáze ERP to nepatří), něco člověk třeba sám tvoří: interní dokumentaci (sesbíraná data a poznámky) k nějakému "případu", archivní ovladače pro konkrétní model či rodinu hardwaru, nebo nějaký content na web, nebo data k projektu (libovolný ne-IT obor), nebo třeba softwarový projekt nebo tak něco na ten způsob...

Prostě fůra souborů, které člověk buď někde získá, nebo sám vytvoří, a nerad by o ně přišel.
A člověk pracuje ve firmě/organizaci, a v kolektivu třeba sypou některé druhy takto získaných dat "na společnou hromádku" (sdílejí tu hromádku dat v pravém slova smyslu). A potřebují se v tom kolektivně orientovat, nastavit nějaká pravidla, jak strukturovat strom adresářů apod.

Teď ponechme stranou, že jsou v kolektivu lamy, které mají mentální problém pobrat stromovou strukturu adresářů jakožto velmi základní a obecný koncept. A sypou svoje data kam je zrovna napadne, tak jako že šli zrovna okolo. Sdílený fileserver pak vypadá jako předměstí v banánové republice bez svozu odpadků.

Na druhé straně jsme krasoduchové jako já, kteří se tím snažíme zabývat koncepčně, v rovině "datového modelování a metamodelování" - a nejsme z toho o moc moudřejší než početná "střední vrstva" všelijakých kolegů a šéfů, kteří jsou mentálně někde mezi = nevidí tu hrůzu v celé koncepční hloubce a bojují s tím jak umí, tzn. částečně ad hoc, mají sklon podlehnout reklamě dodavatelů NASů, softwarů na "geniální document management" apod.

V zásadě je problém v tom, že naprostá většina konvenčních filesystémů prezentuje uživateli "strom adresářů". Ten strom je vlastně index, pro jednoznačnou (a jedinou?) adresaci přístupu k datovým objektům (souborům). A problém je v tom, že koncepčně můžeme mít mentální problém říct, který aspekt/atribut/kritérium souboru má být určujícím pro třídění = pro formování té stromové struktury. Příklady možností:
- per uživatel (jasně, máme home adresáře)
- per zákazník
- per "projekt"
- per značka/model/rodina hardwaru
- per oddělení/oblast interních činností ve firmě
Který aspekt zvolit jako primární? Je vůbec některý z nich "nepochybně obecně primární"?

Můžu uvažovat tím směrem, že si prostě jeden aspekt jako primární zvolím, a tento použiji pro zatřídění do stromu souborového systému. A následně se budu snažit použít třeba symlinky nebo "extended attributes" nebo třeba klikatelné indexy v HTML formátu, abych zařídil "sekundární odkazy", které neznamenají "vlastnictví" objektu ve stromě (tím je primární umístění). Bohužel operační systémy mi tuto bohulibou "anotační činnost nad primárním souborovým systémem" nijak neusnadňují, znamenalo by to používat nějaký dodatečný software, řešit multiplatformnost (bye bye symlinky a xattr) apod.

Výrobci OS dokáží ještě tak propašovat do OS "indexační engine", který pravidelně ráno po spuštění počítače sežere na hodinu 100% disk IO kvůli reindexaci...

Anebo prostě cpát BLOBy do databáze a dávat jim nějaké tagy, podle kterých jsou dohledatelné. Ať už ty bloby jsou primárně umístěné jako soubory na disku v mělké/tupé adresářové struktuře, nebo přímo v RDBMS.

Interní dokumentaci lze spravovat třeba v nějakém Wiki-based enginu... prostě hypertext. Což je ale práce navíc, a nakonec to stejně moc neřeší, "kam sypat bloby všeho druhu a jak v nich udržovat pořádek".

Pokud se vrátím na zem k obyčejné adresářové struktuře, tak řekněme, že lidi dostanou home adresáře na fileserveru, do kterých si tradičně navzájem nevidí (za normálních okolností), a pak bude existovat nějaký "sdílený share", kam můžou všichni, případně mají nějak rozparcelováno uživatelskými právy, kdo smí kde zapisovat/mazat apod. A pak se podrobněji uplatní nějaká kritéria, jak věci podrobněji třídit.

A teď si vemte, že ten sdílený share je někde na fileserveru. A lidi mají každý noťas, s ním cestují, a třeba taky chtějí pracovat offline, nechtějí být závislí na internetové konektivitě (protože VPN). To znamená, že si chtějí některé věci zrcadlit na lokální disk v noťasu. Ale jaksi nejde, aby si každý ve firme synchronizoval na své noťasy celý fileserver - prostě z kapacitních důvodů. Řekněme, že lze realizovat synchronizaci "home adresáře". Nojo, ale co věci na sdíleném sharu? Synchronizovat jednotlivé foldry, které si uživatel nějak označí? To už zase vyžaduje netriviální pozornost. Nebo mít pravidlo "pracuju na noťasu, a co vytvořím v tomhle adresáři, to se syncne na server, ale nikoli naopak"? Co když na jedné věci pracuje víc lidí, a třeba se naštěstí nepotkávají nad jedním souborem (není třeba řešit slučovací konflikty) ale hodilo by se, synchronizovat množinu souborů?

Jasně, existují specializované "softwarové systémy" pro konkrétní použití: podnikové aplikace (na škále mezi účtem a ERP), existují systémy pro správu verzí zdrojáků (GIT a jeho poddaní), řadil bych sem i kanonické "document management systémy" třeba na ISO dokumentaci, nebo třeba obyčejnou DokuWiki apod.

Zůstaňme ale ještě chvíli u "holých souborů v adresářovém stromě". Realita je taková, že se zvolí nějaké kompromisní uspořádání, a ono to nějak (kompromisně) funguje.

Ďábel se ovšem skrývá v detailu a občas se ohavně zasměje - třeba ve chvíli, kdy šéf prohlásí "potřebujeme zlepšit zálohy". A má představu, že zařídíte zálohu toho kompostu na celofiremním sdíleném svazku, nejlíp se zachycením chronologie. Toto na prostoru, kam lidi ještě s bídou mentálně zvládnou sypat čerstvá data, ale nejsou už mentálně schopni, třeba jednou za čas uklízet = odmazávat nepotřebné staré verze dočasných imagů toho či onoho apod. Nemluvě o vysloveném odpadu, který tam nikdy nepatřil. Třeba narazíte na to, že někdo už pár let do GITu ukládá archiv surových videosekvencí z nějakého přístroje pro kontrolu jakosti... nebo někdo navrhne, že se do ERP mají archivovat instalátory ovladačů a doprovodného softwaru toho či onoho... (a zálohy ERP jsou ty nejpečlivější, co máme).

Takže můžete nakoupit veliký storage, který Vám bude s nějakou rezervou stačit na aktuální rozměr nahromaděného kompostu. A můžete se snažit o deduplikaci. A prostě to urvat hrubou silou. Proti Vám stojí rostoucí dav bezelstných užovek, které se o pořádek nestarají do chvíle, dokud jim nepřeteče disk - a pak mají sklon řešit problém tím, že žádají disk nový a větší, nebo naopak mažou bezhlavě i věci, které by třeba někdo jiný rozhodně zatím nemazal apod.
A v mnoha případech je pravda, že hardware je levný, zato omylem smazat nějaká unikátně pořízená data (třeba i poměrně objemná) může hodně bolet, i ve finančním vyjádření.

Nebo si přiberete k dosavadnímu popisu práce ještě roli "datového pedanta a uklízečky". Budete pravidelně pročesávat diskový prostor a hledat nápadně velké objemy dat, a prudit jejich vlastníky s dotazem, zda je to ještě potřeba, zda to tam vůbec někdy patřilo, zda to náhodou "podle zavedených konvencí" nepatří ve stromě adresářů někam úplně jinam, nebo aspoň o úroveň níž, apod. Tzn. ono to taky znamená, hrabat se lidem v "soukromém" nepořádku. A při tom neustále koukat na zaplnění záložního storage.

Když za někým přijdete, že byste potřeboval, aby si udělal pořádek v datech, zhruba "dle takových a takových zásad". Víte jak to skončí? U mě většinout tak, že mu ten pořádek musímu udělat já. Za různých okolností jsem se k tomu už párkrát dostal (zálohy, migrace, přetečení disku, disaster recovery). Prostě lidi jsou ještě schopní uklidit si na stole - ale uklidit si na harddisku? :-DDD

Přiznám se, že jsem tohoto "v podnikovém rozměru" naštěstí zůstal zatím převážně ušetřen, protože jsem nikdy nedělal správce fileserveru ve firmě větší než malé - a v malém kolektivu se věci snáz řeší "out of band", když se všichni denně vidíme navzájem... Mohu se komukoli osobně vysmát v odpověď na dotaz "ty Franto neměl bys někde volných pár desítek TB? já bych tady potřeboval něco dočasně odložit / zazálohovat"...

Podle mého je to prostě boj. Je to o osobním sklonu k pořádku (nebo o jeho pravém opaku). A pak ten hlavolam, podle čeho soubory třídit, když si musíte zvolit pouze jednu primární hierarchii, a implementovat "druhotné paralelní hierarchie" je problematické. A připadá mi, že je ten problém posledních 30 let pořád tak nějak stejný - nebo jsem šeredně zaostal.

Takže končím s vynalézáním suché vody (četli jste někdo Neználka?) a jdu zas něco kompromisně rozseknout.

Z toho, že existují a fungují velké firmy, usuzuji, že spousta těch dílčích "problémů", o kterých fantazíruji, je dávno vyřešená (= vynalézám kolo). Ostatně jsem od svých zákazníků tu a tam nějaké rady a postupy z "corporate" prostředí zaslechl :-) Naschvál je nebudu citovat.

K nakousnutí tohoto tématu ve fóru mě poňouklo, že na to téma nevidím nikde nic sepsaného "v kostce" - jako že akademickou publikaci, nebo nějaký "best practices" blogospisek, ani si nepamatuji, že by o tom někdo třeba tady na rootu zeširoka debatoval. Řeší se tu věci jako ZFS nebo CEPH, ale to jsou technologické vrstvy pod VFS, které se snaží "vstřebat cokoli, co na ně užovky nahází a nějak se s tím důstojně vypořádat", se slušnou průchodností, redundancí apod. Mě jde spíš o to, jak zajistit pořádek ve strukturách, které jsou uživatelům viditelné a jimi ovlivnitelné - k čemu je vést, jaká jim stanovovat pravidla, jak uživatelům zjednodušit život v této rovině. Aby příště našli, co dneska někam uložili/zatřídili. A aby to dokázal najít taky někdo jiný.

Koho jsem pohoršil mělkostí této své halucinace, tomu se omlouvám.
Uvítám jakékoli reakce - asi už mě znáte...
A pokud se mi podaří vyprovokovat k věci flame war, tak možná tím líp :-)

3

Hardware / Prodává se nový noťas se 2x SODIMM slotem?

« kdy: 10. 09. 2021, 22:11:57 »

Dobrý den vespolek,

řekněme "z dlouhé chvíle" si aktualizuju představu o trhu "levnějších" notebooků a žasnu, kam se branže posunula. Točivé disky pryč, SATA SSDčka ve 2.5" formátu pryč, M.2 NVME SSD běžně půl tera, s trochou štěstí druhý M.2 slot k dispozici...
V jednom nejmenovaném e-shopu jsem zjistil, že už jenom menšina nabízených strojů má metalický RJ45 Ethernet - jako že "normálním lidem přece stačí wifi". No děkuju pěkně...

A proč vlastně píšu = můj dotaz: dělá se vůbec ještě nějaký noťas, který by měl 2x SODIMM slot?

Všecko co jsem viděl, má jeden kanál zaplácnutý 4 GB onboard, a na druhém kanálu SODIMM slot, běžně osazený 4 GB. Vyšší modely 8 GB natvrdo onboard + 8 GB ve slotu - ale 16 GB už jsem viděl jedině v kombinaci se stand-alone grafikou, což osobně nepreferuji (stačí mi IGP, taky míň žere a motherboard je s ním jednodušší). Na tomhle mě štve, že jeden kanál RAM má natvrdo konkrétní kapacitu a rychlost. Takže pokud osadím větší SODIMM do slotu, většina kapacity RAM pojede neprokládaně. Kromě toho onboard bývá poměrně malá kapacita, čímž přijdu do budoucna téměř o půlku kapacity, kterou by procesor zvládl pobrat. Asi planned obsolescence :-(

Je to divná doba. Jestli máte někdo přehled, tak mě prosím nasměrujte. Díky za pozornost :-)

4

/dev/null / Ověřování vlastnictví domény TXT záznamem - divná móda...

« kdy: 19. 02. 2019, 11:27:28 »

Já jsem asi vážně mimo a asi už i dost dlouho. Přišel kolega "hele potřebuju TXT záznam v DNS, kvůli jednomu kancelářskému SW balíku. Prej abych dodavateli ověřil, že legitimně užíváme doménu, na kterou je u nich v cloudu napojené naše předplatné, které mám správcovat." Zdvihl jsem obočí, na ověření identity u projevu vůle mezi firmami jsou přece dávno zavedené jiné postupy a inštrumenty, ale říkám "jasně, vím co je TXT záznam, tak mi dodej jak se má jmenovat a co má obsahovat". No a trochu mě nadzdvihlo, když mi přišlo "jméno: @"  . To si jako třetí strana dupne, že chce svůj TXT záznam přímo na 2nd-level jméno naší DNS domény?

No evidentně ano. Pokud se týče mého duševního rozpoložení, trochu mě uklidnilo, že ten TXT záznam na 2.úrovni není exkluzivní. A nakonec jsem zjistil, že zmíněný konkrétní provozovatel cloudové aplikace tuhle fintu zřejmě sám nevymyslel.

Není potřeba ani složitě googlit, kdo všechno tohle svým klientům dělá. Zkuste si vypsat "host -t txt $domena" kde za $domena dosaďte 2nd-level doménu libovolné veliké firmy nebo třeba úřadu na celostátní úrovni (mluvím o firmách v roli dotčeného uživatele).

Kde je nějaká ohleduplnost / pořádek? Přístup "řádného hospodáře" ve správě DNS? Vždyť i DKIM si skromně vystačí se jmény čtvrté úrovně (jsou navěšena na jediném jméně 3.úrovně _domainkey). Kdyby se tahle móda (každý svůj TXT záznam na 2nd-level doméně) rozmohla i v druhé a třetí lize SAAS poskytovatelů, tak se nám to DNS pěkně zaplevelí. Celé to vypadá jako přetlačovací hra. Kdo posprejuje víc nároží svojí muří nohou. Kdyby se tohle standardizovalo = vyrobit na to well-known subdoménu třetí úrovně např. _owner_validation (helemese podtržítko), byla by to pro rozpustilé megakorporace jistě mnohem menší sranda. Hehe oni to po sobě chtějí nejspíš i *navzájem* ;-)