Distribuição IEC104

[enge...@gmail.com]

Boa tarde!

Estou tendo problemas com uma distribuição em IEC104 no SAGE, onde no início da comunicação o SAGE derruba a conexão do mestre. Analisando pelo Wireshark verifiquei que o logo no início do TCP, o SAGE envia um pacote FIN.

Pelo Syslog, verifiquei a seguinte mensagem de erro:

iec4t(sage)[4917]: Rejeitada conexão do IP 172.16.100.16 no canal 1 por não haver conexoes locais

Já verifiquei configuração de placa, arquivo hosts, cnf e aparentemente está tudo ok.

A mesma base, quando testada em bancada comunicou perfeitamente.

Alguém tem uma ideia do que possa ser?

No meu entender alguma configuração relacionada ao servidor e não estou conseguindo identificar.

Obrigado!

[Fabricio Beltram]

Ola'. Boa tarde!

Existem muitas possibilidades envolvidas nesse caso.

Quando você mencionou "logo no início do TCP". Isso quer dizer no momento do 3W handshake, ou o FIN eh enviado depois do 3W handshake?

Para facilitar a análise seria legal você compartilhar o seu arquivo de hosts, a configuração da sua entidade CNF e também o arquivo pccap do wireshark.

Aqui vai algumas dicas para encontrar o problema:

- Identifique quando a conexão está sendo finalizada. Se eh antes de concluir o 3WH aí você precisa olhar o socket do processo i104t. Usa o comando netstat ou o ss para analisar o estado dos sockets. Deve haver um socket  tcp escutando na porta 2404.

- Eu nao me lembro muito bem como o SAGE faz para aceitar ou não uma conexão no socket. Se eu nao me engano tinha uma relação com o IP que você associou no hosts para aquela determinada linha de comunicação. Isso pode estar fazendo com que o SAGE descarte um pedido de conexão vindo do IP do cliente. Eu acredito que esse filtro deve estar associado ao bind da conexão vinda do cliente para o socket do servidor, então esse problema resultaria em fechar a conexão antes de concluir o 3WH.

- Se a conexão eh finalizada depois do 3WH isso quer dizer que o problema passou da camada de transporte e deve estar relacionado com a camada de aplicação. Ai aqui já começa a complicar porque tem várias possibilidades. No wireshark da para saber qual mensagem eh responsável por terminar a conexão.

Saudações 

--
Você recebeu essa mensagem porque está inscrito no grupo "Usuários do SAGE" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para usuarios-do-sa...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/usuarios-do-sage/20141ee4-8bf3-49f2-9af0-51b2d0ecc40en%40googlegroups.com.

--

Fabrício Beltram

[Allan Magri]

Oi, boa tarde. 

Na sua configuração tem pelo menos uma aquisição 104? (ou aquela falsa aquisição)?

Att

Am Di., Aug. 25, 2020 at 13:37 schrieb enge...@gmail.com

<enge...@gmail.com>:

--

[enge...@gmail.com]

Bom dia!

Após verificar e reverificar as configurações, reiniciei o servidor do SAGE e a comunicação estabeleceu, rodando a aplicação Mestre 104 em um notebook conectado diretamente a porta Ethernet designada para a distribuição.

Pois bem, trouxe a aplicação para o Centro de Operações, ao tentar conectar o erro retornado é outro. Quando inicia a comunicação, o Mestre conecta-se ao Escravo, porém logo retorna o erro WSAECONNABORTED.

Pesquisando sobre na internet é um erro muito genérico, mas vi algo sobre timeout e coisas do tipo.

Alguém já passou por isso?

Segue abaixo trecho do log da aplicação Mestre.

11/09/2020 07:55:56.186 (0B9C) IOKIT CONNECTING...

11/09/2020 07:55:56.186 (0B9C) SOCKET connecting socket to '172.16.0.41' on port 2404...

11/09/2020 07:55:56.202 (0B9C) SOCKET socket connected to '172.16.0.41' on port 2404 (local port 49270)!

11/09/2020 07:55:56.202 (0B9C) IOKIT CONNECTED!

11/09/2020 07:55:56.202 (0DEC) DRIVER RUNTHREAD: Connected

11/09/2020 07:55:56.202 (0DEC) DRIVER Station 1.101: [alwaysactive,active,linkActive,*ACTIVATENOW]

11/09/2020 07:55:56.202 (0DEC) DRIVER LinkLayer104: interface connected, counters reset

11/09/2020 07:55:56.202 (0DEC) DRIVER Station 1.101: [alwaysactive,active,linkActive,*activateNow]

11/09/2020 07:55:56.202 (0DEC) DRIVER Station 1.101: [alwaysactive,active,*LINKACTIVE,activateNow]

11/09/2020 07:55:56.202 (0DEC) DRIVER Station 1.101: [alwaysactive,*ACTIVE,LINKACTIVE,activateNow]

11/09/2020 07:55:56.202 (0B9C) IO TX:  68 04 07 00 00 00

11/09/2020 07:55:56.202 (0B9C) FRAMES   >> STARTDT ACT

11/09/2020 07:55:56.202 (0B9C) IO TX:  68 0E 00 00 00 00 64 01 06 00 65 00 00 00 00 14

11/09/2020 07:55:56.202 (0B9C) FRAMES   >> IFRAME[14] (SSeq=0,RSeq=0) [C_IC_NA_1=100,cnt=1,cot=6(act),addr=101,orig=0] ADDR=0 QOI(20)

11/09/2020 07:55:56.233 (0DB8) TAG <== (0.000) Tag(0.992.0.0).ReadValue = (07:55:56.233) 1

11/09/2020 07:55:56.233 (0DB8) TAG <== (0.000) Tag(0.998.0.1).ReadValue = (07:55:56.233) 2

11/09/2020 07:55:56.248 (0B9C) SOCKET recv() returned error WSAECONNABORTED (10053)

11/09/2020 07:55:56.248 (0B9C) SOCKET socket closed

11/09/2020 07:55:56.311 (0B9C) IO RX:  TIMEOUT

11/09/2020 07:55:56.311 (0B9C) IOKIT CONNECTION LOST!

11/09/2020 07:55:56.311 (0B9C) IOKIT Request handler disabled

11/09/2020 07:55:56.311 (0DEC) DRIVER RUNTHREAD: Disconnected

11/09/2020 07:55:56.311 (0DEC) DRIVER LinkLayer104: interface disconnected, counters reset

11/09/2020 07:55:56.311 (0DEC) DRIVER Disconnecting slave station...

11/09/2020 07:55:56.311 (0DEC) DRIVER Station 1.101: [alwaysactive,ACTIVE,*linkActive,activateNow]

11/09/2020 07:55:56.311 (0DEC) DRIVER Station 1.101: [alwaysactive,*active,linkActive,activateNow]

11/09/2020 07:55:56.311 (077C) DRIVER *** Error:  Application command 'GeneralInterrogation' cancelled

11/09/2020 07:55:56.311 (077C) DRIVER GeneralInterrogation: failed to send/receive activation command (forcing disconnection)

11/09/2020 07:55:56.311 (077C) DRIVER Disconnecting slave station...

[Fabricio Beltram]

Ola',

Esse seu log ajudou um pouco mais do que a pergunta original, mas ainda não é o suficiente para determinar a raiz do problema. A melhor opção sempre será um arquivo de captura do wireshark. Com o wireshark podemos observar todos os bytes o que facilita muito a análise.

Uma coisa é certa seu problema não está relacionado com as camadas abaixo da camada de transporte, pois no log da para ver que o Mestre disparou o STARTDT ACT isso só acontece após o 3WH do TCP ter sucedido. Da para ver até um pedido de Interrogation Command o que me leva a acreditar que o SAGE respondeu o STARTDT.

Eu tenho dificuldades em lembrar os detalhes, principalmente o protocolo 104 que não trabalho no dia a dia a pelo menos uns 6 anos.

Me lembro que o 104 tem um controle específico de umas mensagens de controle com alguns parâmetros que precisam estar alinhados. Esses parâmetros na sua maioria determinam como o protocolo estabelece e controla o link da camada de aplicação. Procura aí por: t0, t1, t2, t3, k, w.

Dependendo do link que você tem hoje entre o seu SCADA e o SAGE podem estar acontecendo atrasos que podem exceder os limites desses parâmetros de controle fazendo com que a aplicação feche o socket atual para tentar estabelecer uma nova conexão.

Por enquanto estou apenas imaginando os possíveis problemas, como já disse antes, no wireshark você conseguiria acompanhar melhor e saber se a causa da desconexão está relacionada a esses parâmetros.

Outra coisa que eu sugiro 'e verificar se o SAGE está usando o Test Command para controlar o status da conexão, se sim, verificar se o Mestre tem suporte a responder o Test Command. Por que se o SAGE não receber a resposta do Test Command ele vai desligar a conexão. Tem como desligar esse parâmetro no SAGE, mas você perderá a possibilidade de monitorar o estado da camada de aplicação pelo SAGE o que pode ser um problema para redundância de canais.

Abraços,

Belém

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/usuarios-do-sage/ddc04bd6-aa79-4546-a095-41830ed3081dn%40googlegroups.com.

--

Fabrício Beltram

[Roberto Queiroz]

Fabrício,

Pelo log, a negativa de conexão aconteceu logo no início. As desconexões causadas pelos mecanismos T1, T2 e T3 acontece depois de algum tempo (que na maioria dos casos poderia ser protegida protegida pela janela k-w, após a conexão estabelecida com troca de mensagens).

Para que o sage possa começar a responder a GI, é necessário que aconteça primeiro a resposta ao STARTDT. Nesse caso, o mestre/cliente envia o STARTDT act 68 04 07 00 00 00 e o escravo/servidor responde com STARTDT com 68 04 0B 00 00 00. Caso o escravo não responda, haverá desconexão por T1, que não me parece ser o caso, visto que no LOG enviado pelo colega acontece, a desconexão acontece dentro do mesmo segundo.

Veja a figura da norma exemplificando essa situação:

Sem o log do Wireshark fica praticamente impossível fazer uma análise mais detalhada.

Outro ponto que o Alan Magri alertou alguns dias atrás, é que o SAGE precisa de uma conexão de aquisição para que a conexão de distribuição possa funcionar adequadamente (seja uma aquisição real ou uma aquisição DUMMY).  Sem isso, nem dá pra começar a brincar.

Quando a pegar um "LOG mais isento" dessa comunicação, a sugestão do Fabrício é perfeita. Faça uma captura com o WIRESHARK ou um TCPDUMP (comando do linux sudo tcpdump -i placa de rede host IP -s 2000 -n -w arquivo.cap). Lá conseguiremos ver os mecanismos do TCP IP e também as mensagens do protocolo IEC104. 

Depois das duas ações, fica mais fácil entender o que está acontecendo.

Abraço,

Roberto Queiroz

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/usuarios-do-sage/CAHjcKJyJcdCkTWf1AWqZXGrQkiiT9LxT27o9SWtfDrzvMBpv9Q%40mail.gmail.com.

--

Roberto Queiroz

rjnqu...@gmail.com

Tel: 21 98153-0936

[Fabricio Beltram]

Fala Roberto!!! Tranquilo por ai!?

Pois eh, ja estou enferrujado ;). Vou precisar de um outro curso daqueles de protocolos e ASE2000 que você me ensinou, hahaha. To lembrando aqui daquele voo^ para Vilhena que você foi me ensinando a ler os bytes dos protocolos com o ASE.

Realmente no log não da para ver a resposta do STARTDT eu imaginei que tinha passado por que vi essa mensagem aqui. O C_IC_NA_1 eh o Interrogation Command ne?:

11/09/2020 07:55:56.202 (0B9C) FRAMES   >> IFRAME[14] (SSeq=0,RSeq=0) [C_IC_NA_1=100,cnt=1,cot=6(act),addr=101,orig=0] ADDR=0 QOI(20)

Ai presumi que o STARTDT já havia ocorrido mas a ferramenta não escreveu no log. Foi pura suposição minha :-).

Vamos esperar pelo log que aí o sucesso é garantido.

Abraços

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/usuarios-do-sage/CAMXK99OHUU3ijP1jCueKzXQeK%3D8rUmeO_Xt1Wz%3D0fC8ceO%3D%2BOA%40mail.gmail.com.

--

Fabrício Beltram

[enge...@gmail.com]

Bom dia pessoal!

Desculpe o longo período sem informações, porém este assunto ficou parado um tempo e agora está retornando.

Realizando alguns testes ontem, percebi o seguinte comportamento:

- A comunicação está ocorrendo Ok.

- Se por algum motivo a comunicação é interrompida, queda de link por exemplo, ou se para o mestre 104, ao tentar conectar novamente não consegue por um longo período.

Analisando o log do mestre 104, no caso Elipse, é possível verificar que o SAGE não está respondendo a mensagem de STARTDT.

Passa a impressão de que o SAGE está se mantendo preso a antiga conexão e depois de um longo tempo, aproximadamente 3 horas, ele aceita a nova conexão e volta a comunicar.

[enge...@gmail.com]

Realizei mais alguns testes e observei a seguinte situação, com relação ao primeiro frame referente a interrogação geral:

- Pacote enviado pelo Elipse: 05/02/2021 14:35:28.982 (27F0) IO    TX:  68 0E 00 00 00 00 64 01 06 00 66 00 00 00 00 14

- Pacote capturado pelo Wireshark no servidor SAGE:

- Pacote lido no terminal através do \mmf: 15:35:26 RD[N3_D104P]     10 bytes <- fd 01 00 00 66 00 00 00 00 ff

O horário entre a máquina Elipse e SAGE não está sincronizado, por isso esta diferença. Porém sei que se trata do mesmo pacote pois estou testando em meu notebook através de VM.

Alguém já pegou algo do tipo? O pacote saiu do mestre e chegou na máquina ok, porém o SAGE não compreendeu a mensagem.

Depois os demais pacotes de interrogação geral passam a ficar Ok.

[Ricardo Guedes]

Amigo tenho um problema muito semelhante com a UCS da Arteche, porém a comunicação mesmo sendo desligada a USC e religada não retorna. O SAGE prende a conexão. Elaborei um shell script que piga a USC e caso ela não esteja ativa é feito um desativa apenas no processo i104. Depois de religar a USC a comunicação normaliza. Verificamos questões de sincronismo e tudo estava OK.

[enge...@gmail.com]

Verifiquei que se inibo o processo i104 manualmente e habilito novamente, a comunicação volta.

Pelo Syslog verifiquei que quando o SAGE não está aceitando a comunicação, a seguinte mensagem é reportada:

Mar 19 16:30:46 mso1e1 iec4t(sage)[4774]: Criada a conexao no canal fisico 1 para o IP 172.16.100.16 .
Mar 19 16:31:01 mso1e1 iec4t(sage)[4774]: Erro 4 em recv no canal fisico porta 1.
Mar 19 16:31:01 mso1e1 iec4t(sage)[4774]: Criada a conexao no canal fisico 1 para o IP 172.16.100.16 .
Mar 19 16:31:16 mso1e1 iec4t(sage)[4774]: Erro 4 em recv no canal fisico porta 1.

Acredito ser um bug da versão do SAGE, pois temos nove subestações nesta rede com a mesma versão do SAGE e todas apresentam o mesmo comportamento.

[Fabricio Beltram]

Ola,

Eu acredito que o problema que você descreveu está relacionado com um comportamento já conhecido do SAGE.

Em resumo, o SAGE precisa de uma mensagem da camada de aplicação do protocolo 104 para identificar a queda da comunicação. Por padrão, os usuários costumam utilizar a mensagem TI104 - Test Command. Existe a possibilidade de utilizar a mensagem TI101 - Counter Interrogation Command no lugar do TI104, tudo vai depender se o Mestre é capaz de responder a mensagem do SAGE ou não.

O problema eh que a primeira vez que o SAGE fecha a conexão entre o Cliente eo Servidor um socket TCP é estabelecido pelo sistema operacional e SAGE mantém essa conexão travada, até onde eu me lembro sem o TI104 ou o TI101 o SAGE nunca vai terminar esse socket estabelecido com isso caso a conexão e o link falhe o SAGE ainda vai manter aquele socket travado e você não vai conseguir estabelecer uma nova conexão. Manualmente quando você derruba o processo 104 o SAGE termina aquele socket previamente estabelecido e vai permitir que uma nova conexão seja estabelecida.

Minha sugestão é que você habilite uma das mensagens acima, também tenha em mente que você precisa configurar os tempos e a quantidade de tentativas de conexão antes de o SAGE matar o socket e criar um socket novo. Observe esses parâmetros pois se você colocar um tempo muito alto, quando você testar terá a impressão que não está funcionando, mas está tudo relacionado aos parâmetros que você configurou.

Eu nunca tentei fazer testes com o sistema operacional, mas o Linux permite fazer keep alive a nível do TCP e pode ser uma opção que funcione também, mas nunca fiz isso com o SAGE.

Para sua referência existem os seguintes parâmetros no kernel:

net.ipv4.tcp_keepalive_time

net.ipv4.tcp_keepalive_intvl

net.ipv4.tcp_keepalive_probes

Em resumo, esses parâmetros habilitam o Linux a fazer teste de keep alive a nível do socket TCP. Isso vai dar liberdade ao SO terminar o socket caso o outro Host não responda o keep alive.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/usuarios-do-sage/b3be2d4b-46d4-420a-bc97-5c7dd0a43be0n%40googlegroups.com.

--

Fabrício Beltram

[enge...@gmail.com]

Fabrício, boa tarde!

Obrigado pela resposta.

Uma dúvida. Pelo que entendi, o SAGE deveria fechar o socket TCP após atingido o tempo configurado em AQPOL da entidade CXU sem receber nenhuma mensagem Ok?

No caso da minha aplicação, o mestre não responde ao Test Command, ele pode apenas enviá-lo. Porém, configurei o mestre para enviar um clock synchronization em períodos menores que o AQPOL, justamente para manter o canal ativo.

Se houver uma queda na comunicação que demore por um período maior que o AQPOL, o SAGE deve fechar o socket TCP e aceitar uma nova conexão, Ok? 

[Fabricio Beltram]

Hum agora a memória pode me faltar, hehehe.

Eu acreditava que caso sua distribuição tenha o AQPOL configurado e o Mestre não responda aos pedidos de test command do SAGE, a sua comunicação entraria em um loop, pois o SAGE irá desconectar o canal por falha toda vez que o tempo do AQPOL fosse atingido, tem também um outro parâmetro que junto com o AQPOL diz quantas vezes o tempo do AQPOL deve ser repetido antes de o SAGE forçar a queda do canal. Esse seria o comportamento teórico que eu esperaria quando o mestre não respondesse ao test command.

Pelo seu descritivo me parece que o SAGE está considerando qualquer mensagem da camada de aplicação para manter o link ativo. Me parece que toda vez que ele recebe uma mensagem de aplicação ele zera o contador/temporizador do AQPOL. Eu não me lembro desse comportamento, mas também todos os projetos que eu trabalhei em sua maioria eu pude usar ou o test command ou o counter interrogation sem problemas, pois o Mestre sempre respondia ou um ou outro.

Se o comportamento que você descreveu for verdadeiro, eu creio que vai funcionar conforme o esperado. Caso a comunicação falhe o SAGE deixa de receber mensagens de aplicação e passa a contabilizar o tempo do AQPOL + número de tentativas para falha do canal e assim que atingido o tempo configurado ele vai descartar o socket antigo e permitir que uma nova conexão com o Mestre seja estabelecida.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/usuarios-do-sage/2f314fcc-c537-4bb1-9b86-b6c04d1203a2n%40googlegroups.com.

--

Fabrício Beltram