Port monitor v síti Ethernet
Při oživování komunikací s cizími systémy je neocenitelným pomocníkem tzv. port monitor. Je to funkce nebo zařízení, které umožňuje číst data tak, jak jsou přenášena po linkách, a případně je i analyzovat a tak ihned ukázat příčinu problému.
Některé systémy a jejich vývojová prostředí totiž nemají podrobnější diagnostické nástroje a pokud komunikace nefunguje jak má, projeví se to až na aplikační úrovni: data se nevyčítají, povely nefungují, alarmové maily neodcházejí… Pak nezbývá, než se ponořit hlouběji a postupovat podle klasických pravidel pro diagnostiku:
- Rozdělit si systém na jednotlivé části, do jejichž funkce již hlouběji nevidíme.
- U těchto částí popsat vstupy a výstupy (rozhraní).
- Specifikovat, jaká data máme na rozhraních očekávat.
- Přesvědčit se, zda tam jsou nebo ne – a podle toho příslušnou část opravit.
Právě u posledního bodu bývá problém: musíme se nějakým způsobem dostat přímo na rozhraní a zaznamenat data, která si tato rozhraní vyměňují.
U sériových sběrnic, jako jsou RS232 nebo RS485, obvykle jde připojit se fyzicky přímo na linku a data odečítat přes převodník a monitorovací program (terminál) v PC. V případě komunikace přes Ethernet ale můžeme narazit: pokud jedním z účastníků komunikace není osobní počítač, monitorovací programy typu Wireshark (www.wireshark.org) nelze jednoduše použít. Je to proto, že aktivní síťové prvky – routery a switche – propojují mezi sebou jen zdrojový a cílový port a na ostatní porty není komunikace přenášena. Tím se významně zrychluje přenos dat v síti (kolizní doména obsahuje pouze dvě zařízení). PC je ovšem od komunikace mezi PLC a cizím systémem izolováno.
Platí to i pro případ, že cizím systémem je služba v síti Internet, například pokud PLC komunikuje jako klient pomocí TCP nebo UDP kanálu nebo slouží jako server pro přístup k datům pomocí webového API – i tehdy je monitorovací PC zcela mimo datový tok mezi PLC a cizím zařízením.
Ideální je, když PLC umožňuje přes vývojové prostředí nebo přes vlastní operační systém ukládat výpis komunikace. Ten se pak analyzuje buď „ručně“, pokud jsou pro přehlednost odfiltrované nižší vrstvy komunikace, nebo pomocí příslušného programu – většinou jde o formát Wireshark (soubory .pcap). Nyní se podíváme na jednotlivé možnosti podrobněji.
Monitorování pomocí PC a hubu
Jako nejjednodušší možnost se jeví použít hub. Toto dnes již historické zařízení v podstatě elektricky kopíruje signály z každého portu na porty ostatní (všechna zařízení připojená na hub se nacházejí v jedné kolizní doméně). To sice oproti switchi znamená podstatně nižší datovou propustnost, ale PC s monitorovacím programem (typicky opět Wireshark) pak může přijímat veškerá data, která si mezi sebou vyměňuje PLC a cizí systém.
Problém je v tom, že huby dnes již nejsou běžně dostupné, takže buď nějaký vytáhneme z archivu, nebo si obstaráme zařízení, speciálně konstruované pro odposlech paketů, například Ethernet Tap ioninja.com/hardware/ethernet-tap.html – ten dokonce nabízí vlastní analytický software – nebo Ethernet Sniffer www.midbittech.com. Lze ovšem použít i běžně dostupný router:
Ukládání výpisu komunikace v routeru Mikrotik
Poměrně levnou a dostupnou možností je využít pro skenování síťové komunikace konfigurovatelný router Mikrotik. Nastavení tzv. snifferu se v menu Mikrotiku nachází v menu Tools > Packet Sniffer.
Ve vlastnostech snifferu se v položce File name nastaví jméno souboru, do kterého se budou zapisovat vzorkovaná data.
Na kartě Streaming se dá nastavit konkrétní adresa a port. Sniffer pak ukládá pouze data, která vyhovují daným parametrům. Znamená to úsporu místa v paměti a zvýšení přehlednosti záznamů. U krátkých záznamů v řádu desítek sekund (pokud se nám v tomto čase chyba projeví, jako např. při navazování spojení) toto není nutné řešit, filtrovat záznamy můžeme později v programu Wireshark.
Na kartě Filter se dá v položce Interfaces omezit, na jakém ethernetovém portu Mikrotiku bude Sniffer data číst.
Vzorkování zahájíme stisknutím tlačítka Start. Po skončení vzorkování (tlačítko Stop) můžeme stáhnout soubor se vzorkovanými daty v menu Files:
Soubor ve formátu .pcap, stažený do počítače, již můžeme otevřít v programu Wireshark a prozkoumat zachycenou komunikaci.
Ukládání výpisu komunikace v PLC s OS Linux
Některá PLC (např. Domat IPLC510) umožňují přístup do operačního systému. Pak lze využít program tcpdump. Výhodou tohoto způsobu monitorování je, že diagnostiku lze provést i na dálku, aniž bychom museli k PLC instalovat hub či router a připojovat další počítač s monitorovacím programem. Stačí terminálový přístup do PLC. Při ukládání je užitečné pakety rovnou filtrovat, aby se ukládala jen zajímavá data a omezila se velikost výsledného souboru.
Zde je nutné zdůraznit, že přímý přístup do operačního systému PLC s sebou nese řadu rizik a pokud je vůbec možný, doporučuje se ho používat jen při testech a ne na „živých“ projektech.
Příklad pro BACnet (protokol UDP, port 47808):
Připojíme se na PLC terminálem. V PuTTY spustíme
tcpdump -i eth0 -s 1500 -w /tmp/out.pcap "udp and port 47808"
a veškerá síťová komunikace, která vyhovuje zadanému filtru v uvozovkách, se začně ukládat do souboru s názvem out.pcap. Další možnosti a parametry příkazu najdeme např. na danielmiessler.com/study/tcpdump.
Ukládání je nutné ukončit shozením příkazu pomocí Ctrl-C. Pozor, aby monitoring neběžel tak dlouho, aby byl disk zcela zaplněn! Před započetím monitorování ověřte velikost volného místa na disku. Doporučuje se nenechávat monitorování „bez dozoru“, aby soubor nekontrolovaně nerostl.
V adresáři tmp je pak soubor out.pcap, který stáhneme přes WinSCP a normálně otevřeme na PC programem Wireshark. Po stažení je vhodné soubor z PLC smazat.
Ukládání výpisu komunikace v PLC
Jako příklad uveďme starší podstanice Domat IPLC510. U nich není výše uvedený postup nutný, pokud monitorujeme komunikaci na některém ze standardních komunikačních kanálů. V seznamu proměnných najdeme proměnné, které umožňují logování komunikace v PLC. Jmenují se LogPortMonitor…:
LogPortMonitor.CircularSize.[jméno_kanálu] – určuje max. velikost souboru s výpisem. Po překročení velikosti jsou nejstarší data odmazána. Je-li ponechána na výchozí hodnotě 0, velikost souboru není omezena a může dojít k úplnému zaplnění místa na disku PLC!
LogPortMonitor.Format.[jméno_kanálu] – určuje formát hodnot. Nejčastější jsou 2 (Hex) či 0 (ASCII), dále je možné vybrat sedmibitový ASCII formát (1) nebo dekadicky (3).
LogPortMonitor.[jméno_kanálu] – pokud je v True, komunikace je zaznamenávána do souboru.
Při tomto způsobu monitorování se v PLC neukládá veškerá fyzická komunikace, ale jen data aplikační vrstvy. Například u protokolu Modbus uvidíme pouze data týkající se Modbusu, nikoli už IP adresy a TCP porty, flagy IP protokolu, MAC adresy atd – tedy vidíme totéž, co v port monitoru v SoftPLC IDE. Pro aplikační diagnostiku to stačí. Kdybychom chtěli ale například zjišťovat problémy na TCP vrstvě, jako je navazování spojení, udržování socketu atd., nebo v komunikaci, kdy PLC je v roli serveru, museli bychom použít kompletní sken pomocí příkazu tcpdump – viz předchozí bod (nebo použít externí odposlech – hub, Mikrotik atd.).
Několik příkladů komunikace a vyhodnocení chyby
Při vyhodnocování chyby zkoumáme pakety a hledáme chybová hlášení, případně sledujeme průběh komunikace a hledáme místo, kdy výměna dat přestane dávat smysl. V následujících příkladech jsou jedny z nejčastějších chyb, s kterými se v praxi setkáváme.
Snímky obrazovek jsou z programu Wireshark. Ve spodní části okna je rozebrán kompletní obsah paketu, ale některé informace lze vyčíst již v horní části se seznamem paketů. Je užitečné se nejprve seznámit s možnostmi filtrování výpisu, abychom zobrazení omezili jen na relevantní pakety – na ty, které si mezi sebou vyměňují zkoumaná zařízení, a pokud možno jen na konkrétním protokolu. Pak je výps daleko přehlednější.
Modbus TCP – nelze otevřít port
Z cílové adresy (zde 192.168.1.10) se vrací nějaká odpověď. Pokus o otevření TCP spojení na port 502 nicméně skončí chybou: je vrácen paket (ve výpisu jde o paket č. 12, viz první sloupec) s atributy ACK (potvrzení příjmu) a RST (ukončení spojení), což znamená, že zařízení je na IP adrese v síti dostupné, ale na TCP portu 502 v něm neběží žádná služba. Modbus TCP server tedy nejspíše není na cílovém zařízení povolen nebo nakonfigurován.
Modbus TCP – chybně zadaná adresa registru nebo funkce
Modbus server hlásí při pokusu klienta o zápis dat chybu – Neplatná funkce. Podle dokumentace podporuje server pro zápis pouze F16 (Write Multiple Registers), zde se ale klient snažil zapsat funkcí F06 (Write Single Register).
BACnet – nepodporovaná metoda přístupu k datům
Na požadavek pro zasílání hodnoty při změnách (Subscribe COV) server (adresa 192.168.1.10) v následujícím paketu odpovídá, že tato služba mu není známa (unrecognized service). Klient se tedy musí na hodnotu dotazovat periodicky sám funkcí Read Property – v tomto příkladu to začne dělat automaticky, jak vidíme v následujícím paketu č. 11.
PLC nemůže odeslat e-mail – neplatné přihlášení
V prvním dotazu na DNS server PLC správně obdrží IP adresu mailového serveru a pak s ním naváže komunikaci. Jméno a heslo je posíláno v zakódovaném tvaru (BASE64). Pokus o přihlášení ovšem skončí neúspěchem, byly použity nesprávné přihlašovací údaje. (Server z bezpečnostních důvodů problém blíže nespecifikuje.)
PLC nemůže odeslat e-mail – klient nepodporuje zabezpečené spojení
PLC v roli klienta naváže spojení s e-mailovým serverem. V paketu 372 (číslo je v prvním sloupci zleva) server nabídne možné způsoby zabezpečené komunikace (… STARTTLS…), PLC se ovšem snaží rovnou přihlásit (paket 373, AUTH LOGIN). Tento pokus je serverem odmítnut a spojení je ukončeno, v paketu 542 vidíme vysvětlení: Unrecognized authentication type.
IEC 60870-5-104 Chybně nastavený příkaz Select/Execute
Poslední příklad je již poněkud složitější, ale právě on ilustruje, jak je výpis síťové komunikace užitečný. Protokol IEC 60870-5-104 se používá u dispečerského řízení zdrojů a spotřebičů elektrické energie v rozvodné síti. Komunikační jednotka výrobny (RTU) měla přijmout binární povel s časovou značkou, v protokolu jde o datový typ C_SC_TA_1. Dispečer se snažil jednotku opakovaně povelovat, ale neúspěšně – jednotka na adrese 192.168.1.82 vždy vracela negativní odpověď, tedy povel nebyl přijat:
Bez skenování komunikace bychom věděli pouze to, že zařízení spolu nekomunikují, resp. že jednotka nereaguje na zadané povely. Dispečer neměl k dispozici žádné analytické nástroje, mohl pouze zkontrolovat, že spojení s jednotkou je navázáno a že posílá povel na konkrétní (správný) objekt. Teprve po vyjasnění všech možných parametrů komunikace se ukázalo, že dispečink používá povel Select/Execute a nikoli přímé povelování. To znamená, že prvním příkazem (Select) je jednotce sděleno, že určitý objekt bude nastaven do určitého stavu, což jednotka potvrdí, a teprve následujícím telegramem (Execute) je povel realizován. Jednotka ovšem očekávala přímý povel a na příkaz Select reagovala nepotvrzením (Negative: True).
Po změně nastavení v jednotce (místo přímého povelování bylo aktivováno Select/Execute) již komunikace probíhala správně a povel byl přijat:
Závěrem
Potíže při síťové komunikaci bývají těžko řešitelné, protože mohou mít řadu nejrůznějších příčin – od špatně nakrimpovaných konektorů po chybné nastavení v aplikačním programu. Kvalitní vývojové prostředí (IDE) dovede díky port monitorům a podrobným chybovým hlášením práci usnadnit, ale někdy nepomůže než prohlédnout kompletní komunikaci na všech vrstvách a pomocí výpisu (a samozřejmě znalosti principů příslušné komunikace) zjistit, proč si obě strany nerozumí.
Domat Control System s.r.o. patří k evropské špičce dodavatelů řídicích systémů a regulací pro inteligentní budovy, průmysl a energetiku. Cílem této ryze české společnosti je vyvíjet, vyrábět a dodávat řídící systémy v mezinárodním měřítku.