O počítačích a věcech okolo...

[spm]

Jsem scannoval neznamou sit a kazdej pokus ukaze jinej pocet zivejch hostu... a vypadav tomu i ty, co jinak na icmp i reagujou.

Odesláno z mého SM-N950F pomocí Tapatalk

[HonzaCZ]

Já myslel spíš třeba odkaz na nějaký issue, kde je ten problém popsanej, když je to teda ten 150 let starej bug

[sima]

simo, naprosto te chapu .. velikost je velikost ... ja delal roky (desitky let ) na 15,6'' dipleji ... vse matne, to se mi dari .. a jak jdou roky nahoru, zkusil jsem si poridit 17,3'' a je to neskutena parada .. vsecko je vetsi, lepe na to vidim, netrapim tolik oci
takze ten prechod o velikost nahoru je moc fajn ...

Jj je to tak, já teda mám roky samozřejmě už 15,6 palců ntb-ky, ale jak jsem degradoval na 14 palců a něco tak to už moc nešlo, bylo to ale dáno i horším monitorem obecně, nicméně já hlavně na tom ntb s tím či oným monitorem nepracuji, jen užívám jednoduše užívám, ale i tak je to znát, jj.
Tomáš předsedojc to trefil krásně

[spm]

Já myslel spíš třeba odkaz na nějaký issue, kde je ten problém popsanej, když je to teda ten 150 let starej bug

Našel jsem tohle: https://github.com/nmap/nmap/issues/92

nepátral jsem teda, jestli mám úplně stejný symptomy. Ale 10x puštěnej scan se stejnejma parametrama nareportuje pokaždý jinej počet hostů (na /24 síti). A přitom z toho výpisu vypadávají i relativně rozumný hosti (jako třeba mikrotik), u kterých bych nečekal, že je ten scan složí tak, že nebudou nějakou dobu odpovídat

Mimochodem když už jsme u toho rozbíjení věcí, tak jsem úspěšně našel způsob, jak zlikvidovat síť Zkoušel jsem někde tenhle tool na hledání zranitelností: https://www.greenbone.net/en/vulnerability-management/

Zaujalo mě to a fakt se mi to líbilo. Byl jsem z toho nadšenej až tolik, až jsem to pustil po firemní síti No v napětí jsem to nechal scannovat s mng kartami různých průmyslových zařízení. Ty softwary v tom jsou vážně strašný, takže jsem očekával i strašný výsledky, ale tohle mě překvapilo ještě víc Některý zařízení (asi tak všechno od Schneider Electric včetně ex APC zařízení a pak ještě jeden výrobce) ten scan nepřežijou a začnou se patrně restartovat (nebo minimálně tomu začal padat port na switchi). Nejlepší výsledky byly na malých powermeter (PM5340 myslim ), které se úplně kously a přestaly komunikovat. Musely se ty rozvaděče fyzicky oběhat a poshazovat tomu napájení

No nic, čim dál tim víc mi přichází jako dobrej nápad odstěhovat se mimo civilizaci a pást ovce

[schmako]

Našel jsem tohle: https://github.com/nmap/nmap/issues/92

nepátral jsem teda, jestli mám úplně stejný symptomy. Ale 10x puštěnej scan se stejnejma parametrama nareportuje pokaždý jinej počet hostů (na /24 síti). A přitom z toho výpisu vypadávají i relativně rozumný hosti (jako třeba mikrotik), u kterých bych nečekal, že je ten scan složí tak, že nebudou nějakou dobu odpovídat

Mimochodem když už jsme u toho rozbíjení věcí, tak jsem úspěšně našel způsob, jak zlikvidovat síť Zkoušel jsem někde tenhle tool na hledání zranitelností: https://www.greenbone.net/en/vulnerability-management/

Zaujalo mě to a fakt se mi to líbilo. Byl jsem z toho nadšenej až tolik, …

To byl ten den, jak jsi hlásil, že v práci na ho*no? ))

Odesláno z mého SM-A505FN pomocí Tapatalk

[spm]

Ne, tohle byla taková běžná sranda

[HonzaCZ]

Našel jsem tohle: https://github.com/nmap/nmap/issues/92

nepátral jsem teda, jestli mám úplně stejný symptomy. Ale 10x puštěnej scan se stejnejma parametrama nareportuje pokaždý jinej počet hostů (na /24 síti). A přitom z toho výpisu vypadávají i relativně rozumný hosti (jako třeba mikrotik), u kterých bych nečekal, že je ten scan složí tak, že nebudou nějakou dobu odpovídat

Mimochodem když už jsme u toho rozbíjení věcí, tak jsem úspěšně našel způsob, jak zlikvidovat síť Zkoušel jsem někde tenhle tool na hledání zranitelností: https://www.greenbone.net/en/vulnerability-management/

Zaujalo mě to a fakt se mi to líbilo. Byl jsem z toho nadšenej až tolik, …

Tak tuhle zkušenost nemám, ale zase mám zkušenost, že na Linuxu je ten ARP scan asi tak 5x rychlejší než na FreeBSD. Ale stejně ho mám furt rád.

To druhý je dobrá sranda. Ani ty zařízení nemaj nějaký watchdogy, který by to aspoň za nějakej čas samy shodily?

[Zdvyna]

tak zkusím ten Nmap díky

[spm]

Tak tuhle zkušenost nemám, ale zase mám zkušenost, že na Linuxu je ten ARP scan asi tak 5x rychlejší než na FreeBSD. Ale stejně ho mám furt rád.

To druhý je dobrá sranda. Ani ty zařízení nemaj nějaký watchdogy, který by to aspoň za nějakej čas samy shodily?

Tak s rychlostí jsem problém neměl. Teda, jako, neměřil jsem to, ale bylo to dostatečně rychlý na to, že mě to nějak neiritovalo. Ale to že mi tam chyběly hosti mě sralo teda hodně, jelikož jsem tim očuchával nějakou bordel síť, kde potřebuju všechno najít a zlikvidovat, teda, ehm, učesat

Watchdogy to podle mě nemá (a ty měřáky jinak byly mrtvý přes noc, než to v noci, teda, ráno, kolega fyzicky zresetoval). Ty krámy nezvládaj dost často ani to co maj dělat 3/4 z nich komunikuje modbus TCP protokolem, což je primitivní protokol, kam pošleš dotaz na registr a ono ti to vrátí jeho hodnotu. Víc jak půlka těch zařízení tohle nezvládne na víc než 1 spojení. Takže jakmile si ten port něco otevře, ostatní se na něj už nedostanou. Nebo v lepšim případě se ti stane nějaká nehoda síti, to TCP spojení nějak uhnije a nedostane se už na to ani to zařízení, který to mělo předtím otevřený Prostě mám pocit, že lidi, co nezvládají lepit PHP kód copy-pastem ze stack overflow chodí potom programovat industry zařízení

[jkotek]

Není modbus právě o tom, že máš jen jeden master (pardon, primár) na více otroků? Takže pouze jedno TCP spojení je asi dobře, ne?
Druhá věc je pokud na otrokovi nefungá timeout...

[spm]

No, ne úplně... Existují (patrně déle) varianty Modbus RTU / Modbus ASCII (s tím jsem se teda nesetkal, všude bylo RTU), které běhají po sériových linkách. U těch zařízení, co potkávám, to je v drtivé většině RS485. A ano, v tomhle případě je to čistě master/slave, protože po sériové lince z principu ta komunikace může téct jenom jedna. A v případě RS485 může komunikovat jenom jedno zařízení, takže master se zeptá, čeká, slave odpoví.

S rozvojem ethernetů se pak objevil Modbus TCP, které běží po IP spojení. Ten protokol je paketově hodně podobný té RTU verzi, ale je tam pár rozdílů. Vybavuju si dva - první je, že tam chybí CRC (které zase z principu řeší nějaká vrstva pod tím). A druhý je, že někde na začátku toho paketu je navíc jeden byte, který označuje transakci. Tedy, master si do toho bajtu nacpe nějaký identifikátor a slave když na to odpovídá, tak tenhle byte zkopíruje. Takže nejenom, že by to mělo umět více TCP spojení = více masterů, ale úplně hypoteticky by to mohlo fungovat i asynchronně, kdy se master může ptát dále, aniž by dostal odpověď na předchozí. Alespoň tak si vykládám, že se tam kvůli tomu tenhle bajt dává.

Osobně si myslím, že hlavní důvod, proč to nefunguje, je nejspíše ten, že u drtiny těch zařízení to stejně funguje jenom jako převodník na modbus RTU nebo případně ještě na nějakou jinou, obskurnější, prehistorickou sériovou sběrnici. Tedy že to co přijde po TCP se akorát přebalí do jiného protokolu na sériáku, pošle a co se vrátí se zase pošle zpátky. Což jsme zase zpátky u toho, že většina těch aplikací a programů je někdy ze 60. let minulého tisíciletí. Ikdyž to funguje jako blbej převodník, tak by to mohlo mít buffer, cache, whatever a zvládat ty požadavky obsloužit.

(Tohle je mimochodem taky naprosto skvělá věc na chladících jednotkách jednoho nejmenovaného výrobce. S tou jednotkou se komunikuje právě přes RS485/Modbus RTU. Tedy, ani se s tou jednotkou - komunikuje se tak s jednotkou, co má display. A z ní lze vymlátit informace i o dalších jednotkách - bez displaye - které jsou k ní připojené. A tam je takováhle zhůvěřilost i na tom sériáku - já se zeptám po RS485 a jednotka se pak ptá dál po něčem ještě jiném. Naprosto obskurní na tom ovšem je, že ten požadavek po tom divnoprotokolu trvá řádově sekundy. Tedy, zeptám se jednotky na teplotu a ona třeba za 10 sekund odpoví. Ten display si tohle cachuje, ovšem cachovat to začne až potom, co se na to někdo zeptá. Takže běžný stav po výpadku napájení jednotky s displayem je, že PLC se zeptá jednotky XX na teplotu. Nedostane odpověď, protože 10 sekund na ní nečeká, prohlásí, že jednotka nekomunikuje, chyba. Zkusí to za chvíli. Mezitím někdy v budoucnu jednotka s displayem si tuhle informaci začne cachovat a při příštím dotazu tedy v normálním čase odpoví zpět. PLC se tedy zeptá na další hodnotu z této jednotky a opět nedostane odpověď, protože ten pitomý display se po té hodnotě začne pídit zase až teď. Takže jednotka zase nekomunikuje... A když se vezme, že těch jednotek je na tom jednom displayi třeba 8 a čte se z nich zhruba 20 parametrů, tak se to po tom výpadku napájení sbírá víc jak hodinu, než to začne všechno vracet. Každej blbej bastlíř s arduinem by to zvládnul naimplementovat líp. Ale u industrial zařízení za statisíce Kč to nejde ).

[croctoy]

Ty woe, asi vrátím diplom

[schmako]

Ty woe, asi vrátím diplom

Proč? To jde docela pochopit i když ty zařízení neznám

Odesláno z mého SM-A505FN pomocí Tapatalk

[Kolben]

Ty jooo, nemuzu to najit v kterym vlaknu to bylo. Mam takovy pocit, ze se tu nekdo zabyval opravami PC a notebooku. Chtel bych se ho zeptat, esi nahodou nedoze sehnat chladic (ventilatorek) do Notebooku Fujitshu Lifebook S935.

[quickly]

Goba opravuje nbk