Analisei os logs que o Sidney me enviou, e aparentemente o problema é no... Sistema operacional que está rodando o SCADA.....
Observe o arquivo de captura "Captura
03_UPS_CCO.pcapng",
Ative o filtro de exibição "
ip.addr==172.28.0.1 &&
ip.addr == 172.25.0.33"
Acompanhe os pacotes abaixo:
2915 - O SCADA pede Read Coils
2916 - O clp respode com ack (recebei o pedido de read coils no pacote 2915)
2917 - o clp respode responde o valor de coils.
2918 - O SCADA pede Read Holding Regs e ao mesmo tempo envia um ACK (recebi o valor de Coils no pacote 2917), em 0,23milisegundos
2920 - O clp respode com ack (recebei o pedido de read holding regs no pacote 2918)
2921 - o clp responde o valor de holding regs.
-- O scada não responde com ack (recebei a resposta de holding regs)
2934 - o clp envia de novo o valor de holding regs (202,32milisegundos após envio do pacote 2921)
2935 o scada responde com ack (recebei a resposta de holding regs no pacote 2934) em 0,197milisegundos
o ciclo se repete a cada 1 segundo.
Ou seja... Parece haver um problema no protocolo TCP do servidor..
Ele responde ACKs em menos de 1milisegundo, mas não responde o ACK que indica "recebi o valor de Holding Regs"; só na 2ª vez que o CLP envia o valor de Hlding Regs, e isso acontece 200milisegundos após o envio da primeira resposta - tempo mais que suficiente para o scada ou sistema operacional ter enviado o ack da primeira mensagem.
Problema 2:
Não sei.....
Não há informação nos logs que permite tirar uma conclusão, mas desconfio que seja por causa do problema 1.
Por algum motivo o scada (ou o sistema operacional) deve desistir da conexão e tenta se conectar de novo ao clp. (Mais provável)
ou o clp se cansou e fechou a conexão (menos provável, pois neste caso o clp consideraria a conexão como fechada e aceitaria a nova conexão - vide problema 3)
problema 3:
o scada tenta se conectar novamente ao clp, mas ele usa um número de porta local diferente a cada tentativa de conexão.
Eu presumo que o clp rejeita a conexão com rst pois ele entende que se trata de um outro cliente tentando se conectar, e o clp permite apenas a conexão de um cliente por porta.
Eu presumo que se o scada usasse sempre a mesma porta local para se conectar ao clp, este poderia entender que é o mesmo cliente de antes e aceitaria a conexão.
Ao remover o cabo de rede do clp ele reinicializa todos os processos de rede, e assim aceita a nova conexão do scada.
Conclusão
Precisaria de uma captura do wireshark que tenha o momento que o SCADA tenta se reconectar pela primeira vez, para ver o que pode ter causado a queda da conexão.
Mesmo assim talvez nao seja possível tirar alguma conclusão, pois eu estaria vendo o fluxo de dados sem saber o que aconteceu dentro do clp ou do scada ou do sistema operacional que está rodando o scada.
O que pode ser feito
1) Ver por que o scada (ou o sistema operacional) não responde com ack quando deveria.
Talvez não seja possível, parece ser algo bem intrínseco.
2) Ver se o SCADA pode ser configurado para usar sempre a mesma porta local de comunicação com o CLP e assim TALVEZ consiga se reconectar com sucesso
Prazo de Entrega: 17 de Outubro de 2019