Portál AbcLinuxu, 30. dubna 2025 17:27
24.7.2019 10:23
Max | skóre: 72
| blog: Max_Devaine
24.7.2019 21:51
Max | skóre: 72
| blog: Max_Devaine
24.7.2019 21:54
Max | skóre: 72
| blog: Max_Devaine
26.7.2019 18:11
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Tahle fáma se vytvořila nevím kde a pořád jí někdo opakuje.Pretože ani ty si nepovedal úplnú pravdu o Win a licencie na počet procesorov. O tom že niektoré verzie Win pri zmene HW sa zablokovali atď. Každý proste len vytrhne časť a tú niekde zavesí :)
22.7.2019 13:04
Salamek | skóre: 22
| blog: salamovo
22.7.2019 13:50
Max | skóre: 72
| blog: Max_Devaine
Je to lumpárna, že jeho výrobce neposkytuje ovladače pod opensource licencí. Takhle na to tom ale očividně víc vydělá. Každopádně pokud jste to zvládnul rozchodit za den tak to mi přijde jako super rychlé řešení.
Pravdepodobne ten ovladač obsahuje nejaký kód alebo tajomstvo, ktoré si chcú uchovať. Možno je to zlý kód a nechcu pustiť do sveta informáciu ako zle to majú.
Skutočný dôvod uzavretia poznajú len autori.
Gratuluji. Zdá se, že jste univerzitě ušetřil pár set tisíc za cenu nové licence potažmo pár mega za nový chromatografSchválně, jestli to někdo ocení něčím hmotnějším než je poděkování. Minimálně prémie by byly na místě.
A to, že výrobce neposkytuje k zařízení za pár mega s takto dlouhou životností zdarma ovladače pro novější operační systémy, je skutečně lumpárna. Bohužel ale nic překvapivého.
24.7.2019 09:54
xkucf03 | skóre: 49
| blog: xkucf03
Problém je hlavně v tom obslužném softwaru, který umí spoustu netriviálních věcí co člověk prostě nenaimplementuje za víkend.
To už by ale zase mohlo jít rozchodit pod Wine, ne?
Jinak tyhle problémy znám taky – např. software vyžadující HW klíč do LPT portu (ochrana proti kopírování). Na nových deskách jednak moc paralelní porty už nejsou a jednak i když jsou, tak se to nedá moc virtualizovat. Nejlepší řešení by byl crack, ale ten jsem bohužel na tu legálně koupenou verzi/lokalizaci nenašel. Jinak by tohle ve Wine ale chodilo.
24.7.2019 10:29
Max | skóre: 72
| blog: Max_Devaine
Ani náhodou. Ten SW je dost komplexní záležitost s Oralce WAP5 backendem, několika permanentně běžícími službami a tak podobně. Rozhýbat tohle dostatečně spolehlivě WINEm bych se asi ani nepokoušel, navíc od té věci stejně nemám instalačky :)Problém je hlavně v tom obslužném softwaru, který umí spoustu netriviálních věcí co člověk prostě nenaimplementuje za víkend.To už by ale zase mohlo jít rozchodit pod Wine, ne?
Zavést/promapovat specifický driver do Wine nemusí být triviální a to ani v případě, že jsou k dispozici zdrojové kódy driveru pro Linux i Windows, jako to bylo v našem případě.
Pokud má driver nabídnout i read/write API, tak tato funkcionalita nebyla ve Wine podporovaná, pouze drivery s IOCTL only jsou implementované.
Dotazy a hlubší rozbor viz má komunikace na Wine hq
https://www.winehq.org/pipermail/wine-devel/2013-July/100409.html https://www.winehq.org/pipermail/wine-devel/2013-July/100445.htmlPrototyp takového driveru zde:
http://cmp.felk.cvut.cz/~pisa/ulan/wine/Jinak bych mohl napsat a možná někdy napíši celkem dlouhou litanii na téma open-source, spolupráce v oblasti Laboratorních přístrojů, robotiky a software v České republice. Je nutné si dobře vybírat partnery a kolegy, protože jinak si ostatní ukradnou co mohou, vyberou granty, do kterých ani původní autory nepřizvou a dobře odvedené práce mnoho nebude.
Je v krátkosti k našim open-source projektům v oblasti HPLC
Když jsme někdy v roce 1990 navrhovali novou generaci HPLC přístrojů, tak jsme zvažovali, jak zařídit jejich komunikaci a řízení. Použili jsme základ 8051 multidrop komunikace pro RS-485 navržený Intelem a rozšířili ho o plnou podporu multi-master s deterministickou distribuovanou arbitrací přístupu k médiu, projekt uLAN.
Z soukromého prostředí firmy jsme ho poskytli univerzitě, kde byl náš návrh použitý pro parametrizaci jednotek zapalování. Zároveň byl protokol prvně plně dokumentovaný v rámci mé DP. Prvně existovaly drivery pro 8051, DOS, PMD85, poté pro Linux a port z Linux driveru do Windows. Projekt byl brzy plně otevřený včetně všech variant driverů i infrastruktury firmware pro návrh vlastních řídicích modulů na bázi 8051 a ARM LPC. Myšlenka byla vytvořit kompletní systém ne jen pro analytické použití, ale i pro automatizované řízení preparací, purifikací, výroby čistých látek, léčiv atd. Kromě analytických pum máme vyvinuté i pumpu do 20 MPa 400 ml/min.
Z počátku jsme pro přístroje používali na míru upravený komerční produkt DataApex pro DOS. Když jsme dodali přístroje na přírodovědeckou fakultu UK, tak doktor Jindřich Jindřich projevil zájem o novější software pro Windows a na základě dokumentace ho začal implementovat. Poté jsme spojili síly, roky v rámci možností vývoj platili. Výsledkem je projekt CHROMuLAN. Jeden z prvních kompletně open-source systémů pro vyhodnocování HPLC analýz včetně řízení sestav chromatografických přístrojů a analyzátorů aminokyselin. A to přímo podporovaný a vyvýjený ve spolupráci s týmem, který přístroje konstruoval. Na software se odkazují stovky článků, kdy je použitý i pro vyhodnocování záznamů z jiných přístrojů. Náš zájem byl, aby si ho lidé vyzkoušeli a případně až budou sestavy inovovat, tak zvážili nákup přístrojů od parterů, kteří v naší licenci přístroje vyráběli.
Jenže české univerzity raději platili mnohem více za zavedené značky.
Přitom naše přístroje slouží v několika generacích desítky let a i nejstarší dodaný někdy v roce 1992 do Ústavu organické chemie a biochemie AV ČR dostal někdy okolo roku 1996 bezplatný upgrade firmware, který umožňuje přístroj zapojit i k aktuálním verzím sofware. Základní vrstva komunikačního protokolu včetně plné introspekce datových typů má linkovou vrstvu stabilizovanou někdy od roku 1992, takže shodný zdrojový kód driveru pracuje s PCI kartami a později i USB převodníky od verze Linuxu někdy okolo 1.3.38 (1995), Windows Nt 3.5 s tím že se při překladu umí přizpůsobit i PnP modelu Windows 2000 až 10 32 i 64-bit verzi.
Vlastní řídicí a vyhodnocovací software je poplatný době vzniku, je psaný pro Delphi, přesto jsem investoval značné množství času a i nějaké firemní peníze do portu pod Linux. Varianta pro Linux zatím není plnohodnotná, protože FPC/Lazarus nepodporuje MDI tak, jak byl program napsaný. Ale SW nativně na Linuxu v 32 i 64-bit buildu běží, s přístroji komunikuje a základní vyhodnocování umožňuje. Nechodí overlay režim porovnávání několika analýz a tisk.
Byli jsme otevření i spolupráci s dalšími, kteří by měli zájem software rozšířit o podporu sběru dat a řízení dalších přístrojů. Pro připojení starších detektorů s analogovým výstupem dodáváme AD převodník ULAD32, který lze zapojit do USB a zároveň vytváří bránu pro připojení dalších přístrojů přes naší komunikaci uLAN. Vzhledem k otevřenému protokolu a zdrojovým kódům infrastruktury pro tvorbu firmware není problém zapojit i vlastní zařízení na bázi MCU.
28.7.2019 19:15
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Jinak bych mohl napsat a možná někdy napíši celkem dlouhou litanii na téma open-source, spolupráce v oblasti Laboratorních přístrojů, robotiky a software v České republice.Tak na to sa trasiem ako drahý pes v zime. Mám rád osobné skúsenosti a asi nebudem sám.
Souhlasím, že Delphi/Lazarus již z dnešního pohledu nejsou ideální. Jak pro počítače tak pro embedded HW, analyzátory, demonstrátor nového GUI a HW infúzních pump a další jsme použili a používáme Qt.
Na druhou stranu je Lazarus/FPC zajímavý tím, že binární build z Jessie běží i na Busteru a v podstatě libovolném Linuxovém distru, stejně jako dříve Acrobat reader, bez nutnosti si s sebou táhnout knihovny. Důvod je celkem prostý, objektová obálka, která se s verzí Lazarusu/FPC mění je zalinkovaná staticky a vlastní grafické knihovny Gtk, Glib a spol mají čistě C-čkové API, které je po celou major verzi udržované striktně binárně kompatibilní. Pak vlastně ekvivalent flatpak like runtime je jen seznam major verzí knihoven, které si distribuce normálně dotáhne (pustit libovolný SW tak, aby viděl jen /lib a /usr v kontejneru je na Linuxu téměř zadarmo). Tak to bylo dříve v Unixovém světě se závislostmi vymyšlené. Bohužel požadavek na rychlý vývoj, featury a C++ tohle neumožňují. Vymýšlel jsem mechanizmus, jak definovat objektové ABI tak, aby bylo možné v předcích přidat virtuální metody a dokonce i fieldy, aniž by bylo nutné rekompilovat veškeré objekty, které z daného objektu dědí. Vycházelo mi řešení, které by sice mělo určitý overhead a více symbolů s runtime nastavenými ofsety, ale nebylo by to tak hrozné. V Qt to dříve řešili tím, že pro zachování binární kompatibility v major verzích přidali metodu, co měla být virtuální jako statickou a navázali na ní signál/slot, kterým v potomcích mohli vlastní tělo přesměrovat. V major verzi Qt 5 to ale již neplatí, všechny projekty jsem musel po instalaci Busteru rekompilovat.
Co se týče chromatografického SW, tak když se mám nepodařilo získat komunitu pro CHROMuLAN, tak jsem alespoň podnítil a zasponzoroval vývoj modulů pro OpenChrom, které umí data z CHROMuLANu číst a i lze přes ně připojit naše zařízení. Podporovaný je ale jen základní sběr dat.
Co se týče CHROMuLANu, tak si myslím, že pro vyhodnocování analýz s jednou nebo několika málo liniemi je stále i po desítce let již jen velmi sporadických updatů lepší než datový model OpenChromu a a možná i Clarity. I když její poslední verze neznám. Každá analýza si nese veškerá data nastavení přístrojů a vyhodnocování přímo v sobě. Tím je možné nejen podmínky dokumentovat, ale i po letech použít jako šablonu nové analýzy. Šablonu lze i exportovat a případně z ní oddělit zvlášť metodu vyhodnocování, nastavení přístrojů a časové programy. Všechno jsou to jen větve jednoho datového modelu, které se serializují do shodného, celkem úsporného a rychle načítaného binárního formátu. Přitom v aplikaci jednotný datový model zahrnuje všechny otevřené soubory (analýzy, sekvence, kalibrace) a živými větvemi datového modelu je i stav připojených přístrojů, které lze zápisem položek ovládat, data číst a nastavit pro každou položku periodu obnovování. Datový model přístrojů je pak načítaný přímo z nich. To znamená že i libovolný nový přístroj lze řídit verzí SW, která o něm neměla tušení a propojení používá skripty v Pascalu, takže přizpůsobení bez nutnosti rekompilace je možné i na straně uživatelů.
Vlastní binární formát byl založený tak, že umožnil dopřednou i zpětnou kompatibilitu od založení projektu před téměř 20 lety do dnes. Ano, není to zcela ideální, natažením nových dat do staré verze se přijde o ty položky v objektech záznamu, které stará verze nezná. Vymýšlel jsem i formát, který by i toto zvládal, ale zvítězil pragmatický přístup. Přiznávám, že i s tou zpětnou kompatibilitou to není 100%, protože jednou jsme objevili zanesenou chybu a tu opravili s tím, že z novějších verzí data do té před chybou nahrát nebude možné. Dopředná kompatibilita dat byla zachovaná po 20 let vždy.
Stále si myslím, že by verze pro Linux mohla být užitečná. Spíš již pro pomoc druhým, než pro nás, protože naše projekty dostaly takové rány, že se spíš nevzpamatujeme. Pokud by byl zájem, tak nějakou lehkou pomoc, dokud ještě dýchám a nejsem zcela pod prášky na vymazání mysli, mohu nabídnout. Plán jak technicky rozumně dál mám, ale je mi spíš k ničemu. Systém CHMRuLANího IDLu, který z validních struktur v Pascalu s komentáři generuje kompletní objektový datový model, by bylo možné rozšířit tak, aby vygeneroval buď přímo kód v C++ nebo nějaký jiný formát popisu datového modelu a z něho pak vygenerovat Qt property nebo nějaký jiný objektový model pro C++. Vlastní výpočetní funkce převést z Pascalu do C již není až tak moc práce. Grafy by se v Qt našly možná i lepší a pro výměnu dat mezi GUI aplikacemi a RT daemony pro řízení přístrojů bych nyní volil Silicon Heaven protokol, který navrhl můj kolega pro řízení tramvají https://github.com/silicon-heaven/libshv nebo RTPS protokol.
Pro vyhodnocení jsem měl připravený i koncept, jak implementovat PeakFitting s analyticky spočítanými modely včetně derivací pro mnoho typů peků https://sourceforge.net/p/chromulan/pfit-experiments/ a dizertace https://support.dce.felk.cvut.cz/mediawiki/images/a/a3/Diz_2010_pisa_pavel.pdf.
Pokud by pak někdo měl opravdu o HPLC zájem a chuť spolupracovat a pustit se do seriózního projektu, tak bych byl třeba i pro open-source/hardware řešení. Když by se sehnal crowdfunding na takových 20 přístrojů od jednoho typu, tak máme připravený velmi pěkný projekt analytické HPLC pumpy do 5 ml/min, který náš partner zmrzačil v rámci grantu za 5 mega a tvrdí, že v jím "vyvinutém" přístroji již naše komponenty nejsou a neplatí licence (licence na veškerý náš předchozí vývoj dostali bez počáteční investice do vývoje s tím, že se naše investice zaplatí procenty z prodaných kusů). Ozkoušené máme bloky pro separace do těch 20 MPa 400 ml/min. Dále pumpy do 20 a 100 ml/min, které vykazují výrazně menší rychlost opotřebení ucpávek než konkurence. Naše UV-VIS detektory také při testech vyhazovaly shodné parametry jako nejlepší zahraniční. I po naší likvidaci za peníze z grantu v oblasti analyzátorů aminokyselin, jsme připravovali třeba i pro původního partnera PDA, ale ochota zaplatit výrobu prototypu byla nulová. Vzhledem k tomu, že oficiálně deklarovali, že naše analyzátory již nevyrábí a k tomu, že v oblasti HPLC odmítli navrhované přístroje nebo náš vývoj po výrobě prototypu přímo zmrzačili a ukradli, tak se necítím vázaný smluvním ustanovením, že nejdříve máme nové přístroje v oblasti HPLC nabízet tomu jistému partnerovi. Takže projekt kompletního HPLC je volný. Naděje sehnat partnery je ale mizivá a rád bych viděl alespoň finanční zajištění, které by umožnilo projektům pokračovat, když na mě za posledních nejméně 16 let i při mém značném nasazení nezbyla po zaplacení nákladů ani koruna a šéfové partnerů se ještě tvářili, že jsme drazí a jak je odíráme. Na svých platech spotřebovali víc než byl celý hospodářský výsledek naší firmy za téměř 25 let existence.
Co se týče ECHMET, tak by mě zajímalo, jaké jsou s projektem plány. Zkusil jsme a úspěšně zkompiloval PeakMasterNG, ale pro nějaké otestování mi chybí databáze a nějaký příklad. Chci se i podívat co umí CEval, ale tam zatím s novější verzí GCC narážím na problém s kompilací HVL_MT
/home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp: In function ‘HVL_RetCode LaunchWorkersAndWait(HVL_Range**, const HVL_Context*, double, double, double, double, double, double, double, fpcalcfun)’: /home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp:763:2: error: ‘MPFR_TRY_BEG’ was not declared in this scope MPFR_TRY_BEG ^~~~~~~~~~~~
Mně zcela upřímně taky... :)Co se týče ECHMET, tak by mě zajímalo, jaké jsou s projektem plány.
Zkusil jsme a úspěšně zkompiloval PeakMasterNG, ale pro nějaké otestování mi chybí databáze a nějaký příklad.Hustý... dost dlouho jsem byl přesvědčen, že to podle toho postupu v README nikdo jiný nezkompiluje. Databáze je bohužel dílem někoho jiného, takže švihnout ji jen tak na GitHub pod GPL licencí není dost dobře možné. Řešením je stáhnout oficiální binárku PMNG pro Windows a databázi odtamtud vykopírovat. Návod s nějakými příklady tam je taky - link. Předem se omlouvám za nutnost registrace, z mé hlavy to není a nemohu s tím mnoho udělat...
Díky, mělo by to být opravené. Za tenhle megahack jsem si asi nic jiného nezasloužil. Jinak HVL_MT silně doporučuji kompilovat s podporou MPFR, jinak bude pro praktická data téměř nepoužitelná. (Celá šaškárna sChci se i podívat co umí CEval, ale tam zatím s novější verzí GCC narážím na problém s kompilací HVL_MT
/home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp: In function ‘HVL_RetCode LaunchWorkersAndWait(HVL_Range**, const HVL_Context*, double, double, double, double, double, double, double, fpcalcfun)’: /home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp:763:2: error: ‘MPFR_TRY_BEG’ was not declared in this scope MPFR_TRY_BEG ^~~~~~~~~~~~
MPFR_[TRY|CATCH]_* je odporný workaround chování libmpfr, která v určitých případech při překročení určitého počtu platných číslic bez milosti zavolá abort() a sundá celý program. Doporučuji tuhle hrůzu vyřadit volbou -DCATCH_MPFR_ASSERTS=OFF, měl by to být default.)
Dík, na to použít -DUSE_MPFR=ON jsem přišel. Nepodařilo se mi dostat do EDII, aby libHPCS hledal v /opt/emchet/lib . Tak jsem to zatím na jeden běh ohackoval přidáním příslušného L do generovaných link.txt. Tím jsem vybuildoval CEval, ale opět, nevím kam namířit na EDII, tak aby to chodilo. Mám pouze /opt/echmet/bin/EDIICore .
Skript na vybuildování jsem sestavoval spíš z CMakeLists.txt a pro a pri než podle README. Obecně by se hodilo vytvořit git, který by ty ostatní natáhl jako submoduly a přidal toplevel projekt, který by do ostatních předával cesty. Natvrdo zakódované cesty do home v pri nejsou moc pěkné. Ale plně to chápu a minimálně stylem řešení (Qt5, D-bus, MPFR a i to cmake, které sice nemám nejraději, ale je dnes asi nejpoužitelnější/nejpoužívanější) se mi projekt jako celek líbí a rád bych viděl, k čemu vlastně je. Jestli se v něm dá nějaký záznam zobrazit .
#!/bin/sh EMCHET_INST_DIR=/opt/echmet (cd src/ECHMETCoreLibs && git pull ) || exit 1 (cd build/ECHMETCoreLibs && cmake -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3" -DCMAKE_C_FLAGS="-I/usr/include/eigen3" -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/ECHMETCoreLibs && make) || exit 1 (cd build/ECHMETCoreLibs && make install ) || exit 1 (cd src/HVL_MT && git pull ) || exit 1 (cd build/HVL_MT && cmake -DUSE_MPFR=ON -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3" -DCMAKE_C_FLAGS="-I/usr/include/eigen3" -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/HVL_MT && make) || exit 1 (cd build/HVL_MT && make install ) || exit 1 (cd src/libHPCS && git pull ) || exit 1 (cd build/libHPCS && cmake -DUSE_MPFR=ON -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3" -DCMAKE_C_FLAGS="-I/usr/include/eigen3" -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/libHPCS && make) || exit 1 (cd build/libHPCS && make install ) || exit 1 (cd src/EDII && git pull ) || exit 1 (cd build/EDII && CONFIGURE_ENV="LDFLAGS=-L$EMCHET_INST_DIR/lib" cmake -DUSE_MPFR=ON -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3 -I$EMCHET_INST_DIR/include" -DCMAKE_C_FLAGS="-I/usr/include/eigen3 -I$EMCHET_INST_DIR/include" -D"CMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR" ../../src/EDII && make) || exit 1 (cd build/EDII && make install ) || exit 1 (cd src/ECHMETUpdateCheck && git pull ) || exit 1 (cd build/ECHMETUpdateCheck && cmake -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/ECHMETUpdateCheck && make) || exit 1 (cd build/ECHMETUpdateCheck && make install ) || exit 1 (cd src/LEMNG && git pull ) || exit 1 (cd build/LEMNG && cmake -DCMAKE_CXX_FLAGS="-I$EMCHET_INST_DIR/include/ECHMET/CoreLibs -I/usr/include/eigen3" -DECHMET_CORE_LIBS_DIR=$EMCHET_INST_DIR -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/LEMNG && make) || exit 1 (cd build/LEMNG && make install ) || exit 1 (cd src/PeakMasterNG && git pull ) || exit 1 (cd build/PeakMasterNG && /usr/lib/x86_64-linux-gnu/qt5/bin/qmake ../../src/PeakMasterNG/PeakMasterNG.pro PREFIX=$EMCHET_INST_DIR && make) || exit 1 (cd build/PeakMasterNG && make install ) || exit 1 (cd src/CEval && git pull ) || exit 1 (cd build/CEval && /usr/lib/x86_64-linux-gnu/qt5/bin/qmake ../../src/CEval/CEval.pro PREFIX=$EMCHET_INST_DIR && make) || exit 1 (cd build/CEval && make install ) || exit 1
Při sestavení by mělo stačit použítDík, na to použít -DUSE_MPFR=ON jsem přišel. Nepodařilo se mi dostat do EDII, aby libHPCS hledal v /opt/emchet/lib .
-DLIBHPCS_DIR=/opt/echmet/<adresář s include a lib>...
EDII je samostatná binárka, která běží jako služba. CEval se při prvním startu zeptá, kde má hledatTak jsem to zatím na jeden běh ohackoval přidáním příslušného L do generovaných link.txt. Tím jsem vybuildoval CEval, ale opět, nevím kam namířit na EDII, tak aby to chodilo. Mám pouze /opt/echmet/bin/EDIICore .
EDIICore a v případě potřeby si ho sám spustí. S CEvalem komunikuje buď D-Busem nebo local socketem.
Zrovna QMake je na nějakou uživatelem definovanou konfiguraci docela nešikovný; nacpat parametry buildu aspoň do .pri je zdá se jediné jakž takž schůdné řešení. Řešit to submoduly apod. jsem zvažoval, problém je, že CEval byl původně o hodně jednodušší a spousta věcí se tam doslova a do písmene doprasila jako brutální "afterthought", i ta komunikace s EDII přes D-Bus je tak trochu hack :) To už by se spíš vyplatilo napsat to celé znovu s nějakou modulární a trochu promyšlenou architekturou...Skript na vybuildování jsem sestavoval spíš z CMakeLists.txt a pro a pri než podle README. Obecně by se hodilo vytvořit git, který by ty ostatní natáhl jako submoduly a přidal toplevel projekt, který by do ostatních předával cesty. Natvrdo zakódované cesty do home v pri nejsou moc pěkné.
23.7.2019 18:15
Salamek | skóre: 22
| blog: salamovo
Pokud mas letitej SW, kterej "proste funguje", je dost pravdepodobny, ze ty mesice do jeho odladeni nekdo investoval pred temi lety. A/nebo se uzivatele smirili s nejakymi neduhy, a uz je ani nevnimaji. Ani jedno nebude platit pro novou implementaci.To je jasný, nicméně být majitelem/provozovatelem takového HW tak si minimálně nějakej ten dump komunikace udělám, možná i nějakou předběžnou krátkou analýzu. SW může být sebeodladěnější, ale až ho nebude na čem spustit, nebude to nic platný...
Bacha na to, že Debian 10 používá jako výchozí nftables a pokud chcete filtrovat TCP/IP na bridgi, je lepší se vrátit k iptables...Můžete napsat proč? Já zatím narazil na to, že chybí modul recent (i když možná funguje s tím zpětně kompatibilním
iptables, ale nepřišel jsem na to, jak ho pomocí nft nastavit)
iptables -A INPUT -p tcp -i eth0 --dport 80 -m recent --name flood --hitcount 20 --seconds 2 --rcheck -j DROP iptables -A INPUT -p tcp -i eth0 --dport 80 --syn -m recent --name flood --set -j ACCEPTKdyž přijde SYN paket na port 80, do tabulky "flood" se vytvoří záznam pro zdrojou IP adresu a uloží se do něj nějaký timestamp. Když jich přijde víc, timestampů se uloží víc:
src=92.63.194.15 ttl: 121 last_seen: 4297053550 oldest_pkt: 3 4297037105, 4297053550, 4297053550
To první pravidlo je splněné v případě, že pro zdrojovu adresu paketu je v tabulce 20 záznamů, které nejsou starší než 2 sekundy. Cílem je zablokovat roboty, co považují za dobrý nápad prolézat weby tak, že se na server naváže třicet spojení naráz. Několik spojení se jim povolí, ostatní syn pakety se dropnou a spojení se naváže až poté, co se ten syn paket pošle opakovaně.
Dneska už to není takový problém, takže bych se bez toho pravidla asi i obešel, ale na druhou stranu si říkám, že když je nějaký udělátor, co vezme syntaxi iptables a nastaví NF pravidla, tak by syntaxe pro nft mohla umět totéž...
ct state established,related accept
...
tcp dport http ct state new meter http size 65535 { tcp dport . ip saddr limit rate 10/second burst 20 packets } accept
3.8.2019 11:47
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Před pár dny se GPIB načalo na EEVblog, ale hádám že ovládací software bude i něco počítat a ne jen zobrazovat čísla.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.