O GOOSE aparece na rede, mas o assinante não o processa: um erro na biblioteca libIEC61850

Em 24 de setembro de 2026, os desenvolvedores da biblioteca de código aberto libIEC61850 publicaram a versão 1.6.2.1, que corrige um erro no mecanismo de recepção de mensagens GOOSE. A correção está relacionada ao problema n.º 603, registrado no repositório do projeto em 24 de julho de 2026.

Isso diz respeito, antes de tudo, aos desenvolvedores de produtos compatíveis com a norma IEC 61850 que utilizam a libIEC61850: dispositivos, gateways, controladores, sistemas de software e software de ensaio. Se a versão 1.6.2, lançada em 23 de julho de 2026, entrou num produto, a recepção de GOOSE pode falhar já nas instalações dos usuários finais — embora a troca na rede pareça normal.

Para os engenheiros de proteção e controle, o caso é ilustrativo por mostrar uma situação em que a comunicação de rede funciona corretamente, mas o software de aplicação não processa as mensagens recebidas.

Em que consistia o erro?

Segundo a IEC 61850-8-1, as mensagens GOOSE são transmitidas diretamente em quadros Ethernet. O cabeçalho GOOSE contém o campo Length, que indica o comprimento da mensagem, incluindo os campos de cabeçalho GOOSE e o bloco de dados APDU.

Ao receber um quadro, a biblioteca libIEC61850 verifica se o comprimento real do quadro recebido corresponde ao valor indicado no cabeçalho.

Na versão 1.6.2, surgiu um erro nessa verificação: os quadros cujo comprimento real correspondia exatamente ao declarado eram considerados, por engano, incorretos.

A causa foi a alteração de um único operador de comparação na função parseGooseMessage. Em vez da condição:

numbytes < length + headerLength

era utilizada a condição:

numbytes <= length + headerLength

Aqui, numbytes é o número de bytes efetivamente recebidos, headerLength é o comprimento do cabeçalho Ethernet (14 bytes, ou 18 com tag VLAN) e length é o valor do campo Length do cabeçalho GOOSE. A soma length + headerLength é o comprimento que o quadro deve ter de acordo com o seu próprio cabeçalho.

A verificação correta descarta um quadro apenas se foram recebidos menos bytes do que o indicado no cabeçalho — ou seja, se o quadro está truncado. A verificação errada também o descartava quando eram recebidos exatamente os bytes indicados. Mas é precisamente assim que se apresenta um quadro normal, sem bytes a mais no final.

A biblioteca considerava esse quadro danificado e o descartava antes mesmo de verificar se algum dos assinantes configurados estava inscrito nele. Com o diagnóstico ativado, era exibido o erro «Invalid PDU size».

Por que algumas mensagens GOOSE eram recebidas e outras não?

Um quadro Ethernet não pode ter menos de 64 bytes, ou 60 bytes sem a soma de verificação FCS. Se a mensagem GOOSE for mais curta, o dispositivo emissor acrescenta ao final do quadro bytes de preenchimento (padding). Eles não entram no valor do campo Length.

Por exemplo, se, segundo o seu cabeçalho, um quadro deve ocupar 44 bytes, ele será preenchido até 60. A biblioteca recebe 60 bytes — mais do que o indicado no cabeçalho — e a verificação errada é satisfeita. Esse quadro era aceito.

Se, porém, o quadro ocupa 60 bytes ou mais sem preenchimento, não há nada a acrescentar: são recebidos exatamente os bytes indicados no cabeçalho. No exemplo do relato do erro, esse quadro tem 111 bytes. Eram precisamente esses quadros que a versão 1.6.2 descartava. Como observa o autor do relato, esse é o caso habitual para conjuntos de dados reais: o erro atingia todos os quadros GOOSE mais longos que o quadro Ethernet mínimo.

Assim, a recepção de GOOSE dependia do comprimento do quadro e da presença de bytes de preenchimento, embora a mensagem em si estivesse correta.

Como o problema foi descoberto?

O autor do relato do erro preparou um exemplo reproduzível com um quadro GOOSE de 111 bytes. Com a libIEC61850 1.6.2, a mensagem não chegava ao manipulador do assinante. Após a correção da condição de verificação, o mesmo quadro passou a ser recebido com sucesso.

Em 24 de setembro, outro participante do projeto publicou os resultados de uma verificação independente com dois contêineres Linux ligados por uma rede virtual. No ensaio foram usados os exemplos padrão de publicador e assinante GOOSE incluídos na biblioteca.

Os resultados mostraram que, na versão 1.6.2, as mensagens transmitidas chegavam à interface de rede, mas o assinante não chamava o manipulador de recepção. Após a aplicação da correção, as mensagens corretas passaram a ser processadas.

No mesmo dia, o mantenedor do projeto, Michael Zillgith, confirmou a inclusão da correção e a publicação da versão 1.6.2.1.

O que os desenvolvedores de produtos baseados na libIEC61850 devem fazer

Para fabricantes e desenvolvedores que utilizam a libIEC61850 em seus produtos, a conclusão é direta: o erro está na biblioteca e passa para todo produto compilado com a versão 1.6.2.

• Verificar a versão da biblioteca incluída no produto — inclusive no firmware, nos SDK, em componentes de terceiros e em cópias do código-fonte levadas para repositórios próprios.
• Atualizar para a 1.6.2.1 ou transpor a correção da condição de verificação de comprimento na função parseGooseMessage, caso a biblioteca tenha sido modificada internamente.
• Considerar a própria entrada de rede. Segundo o relato do erro, os quadros entregues à biblioteca via GooseReceiver_handleMessage não têm bytes de preenchimento, por isso qualquer quadro pode ser descartado, e não apenas os com mais de 60 bytes.
• Acrescentar testes de regressão de recepção de quadros GOOSE de diferentes tamanhos: com preenchimento até o comprimento mínimo do quadro Ethernet e sem ele.
• Lançar uma atualização para os usuários, se um produto com a versão 1.6.2 já tiver sido entregue a clientes.

O que isso significa para os engenheiros de subestações digitais

No diagnóstico da troca GOOSE, o Wireshark costuma ser uma das primeiras ferramentas. Se a mensagem está presente na captura do tráfego de rede, tem os endereços e identificadores esperados e a sua estrutura é decodificada corretamente, o engenheiro pode supor que o problema está nas configurações da assinatura ou na lógica do dispositivo receptor.

No entanto, este caso mostra que a presença de uma mensagem GOOSE correta numa captura de rede não garante o seu processamento bem-sucedido pelo software de aplicação.

Ao procurar falhas desse tipo, é importante verificar não só a passagem das mensagens pela rede, mas também o funcionamento do mecanismo de assinatura do software: se a mensagem chega à aplicação, se o manipulador GOOSE é chamado e se a versão da biblioteca utilizada contém erros conhecidos.

Em sistemas baseados na libIEC61850, deve-se dar atenção especial à versão da biblioteca e às mensagens de diagnóstico do receptor. Ao reproduzir a falha, é útil comparar o processamento de quadros com e sem bytes de preenchimento.

Conclusão

O erro da libIEC61850 1.6.2 é um exemplo ilustrativo de uma falha que não surge na transmissão de quadros Ethernet, mas diretamente na implementação de software do protocolo. O problema foi corrigido na versão 1.6.2.1, publicada em 24 de setembro de 2026. Os desenvolvedores de produtos IEC 61850 baseados na libIEC61850 devem verificar a versão da biblioteca que utilizam e, se necessário, atualizá-la em seus produtos.

A presença desse erro numa biblioteca de código aberto não significa que os relés de proteção industriais sejam afetados: isso depende da implementação de software, da sua versão e das alterações feitas pelo fabricante.

Este caso reforça a importância de uma verificação completa da troca GOOSE — da presença da mensagem na rede até o seu processamento efetivo pela aplicação receptora.