Le 24 septembre 2026, les développeurs de la bibliothèque open source libIEC61850 ont publié la version 1.6.2.1, qui corrige un bogue du mécanisme de réception des messages GOOSE. La correction se rapporte au ticket n° 603, enregistré dans le dépôt du projet le 24 juillet 2026.
Cela concerne avant tout les développeurs de produits compatibles avec la norme IEC 61850 qui utilisent libIEC61850 : équipements, passerelles, contrôleurs, systèmes logiciels et logiciels d’essai. Si la version 1.6.2, publiée le 23 juillet 2026, a été intégrée à un produit, la réception GOOSE peut être perturbée dès chez les utilisateurs finaux — alors même que l’échange sur le réseau paraît sain.
Pour les ingénieurs protection et contrôle-commande, le cas est instructif car il illustre une situation où la communication réseau fonctionne correctement, mais où le logiciel applicatif ne traite pas les messages reçus.
En quoi consistait le bogue ?
Selon l’IEC 61850-8-1, les messages GOOSE sont transmis directement dans des trames Ethernet. L’en-tête GOOSE comporte un champ Length qui indique la longueur du message, y compris les champs d’en-tête GOOSE et le bloc de données APDU.
À la réception d’une trame, la bibliothèque libIEC61850 vérifie que la longueur réelle de la trame reçue correspond à la valeur indiquée dans l’en-tête.
Dans la version 1.6.2, une erreur s’est glissée dans ce contrôle : les trames dont la longueur réelle correspondait exactement à la longueur déclarée étaient considérées à tort comme incorrectes.
La cause en était la modification d’un seul opérateur de comparaison dans la fonction parseGooseMessage. Au lieu de la condition :
numbytes < length + headerLength
c’est la condition suivante qui était utilisée :
numbytes <= length + headerLength
Ici, numbytes est le nombre d’octets effectivement reçus, headerLength la longueur de l’en-tête Ethernet (14 octets, ou 18 avec une étiquette VLAN), et length la valeur du champ Length de l’en-tête GOOSE. La somme length + headerLength est la longueur que la trame doit avoir selon son propre en-tête.
Le contrôle correct ne rejette une trame que si le nombre d’octets reçus est inférieur à celui indiqué dans l’en-tête, c’est-à-dire si la trame est tronquée. Le contrôle erroné la rejetait aussi lorsque exactement le nombre d’octets indiqué avait été reçu. Or c’est précisément l’aspect d’une trame ordinaire, sans octets superflus à la fin.
La bibliothèque considérait une telle trame comme endommagée et la rejetait avant même de vérifier si l’un des abonnés configurés y était abonné. Lorsque le diagnostic était activé, l’erreur « Invalid PDU size » s’affichait.
Pourquoi certains messages GOOSE étaient-ils reçus et d’autres non ?
Une trame Ethernet ne peut pas faire moins de 64 octets, ou 60 octets sans la somme de contrôle FCS. Si le message GOOSE est plus court, l’équipement émetteur ajoute en fin de trame des octets de bourrage (padding). Ils ne sont pas inclus dans la valeur du champ Length.
Par exemple, si selon son en-tête une trame doit occuper 44 octets, elle sera complétée à 60. La bibliothèque reçoit 60 octets — plus que ce qu’indique l’en-tête — et le contrôle erroné est satisfait. Une telle trame était acceptée.
Si, en revanche, la trame occupe 60 octets ou plus sans bourrage, il n’y a rien à ajouter : le nombre d’octets reçus est exactement celui indiqué dans l’en-tête. Dans l’exemple du rapport de bogue, une telle trame fait 111 octets. Ce sont précisément ces trames que la version 1.6.2 rejetait. Comme le souligne l’auteur du rapport, c’est le cas habituel pour les jeux de données réels : toutes les trames GOOSE plus longues que la trame Ethernet minimale étaient concernées.
Ainsi, la réception d’un GOOSE dépendait de la longueur de la trame et de la présence d’octets de bourrage, alors même que le message était correct.
Comment le problème a-t-il été découvert ?
L’auteur du rapport de bogue a préparé un exemple reproductible avec une trame GOOSE de 111 octets. Avec libIEC61850 1.6.2, le message n’atteignait pas le gestionnaire de l’abonné. Après correction de la condition de contrôle, la même trame était reçue avec succès.
Le 24 septembre, un autre contributeur du projet a publié les résultats d’une vérification indépendante utilisant deux conteneurs Linux reliés par un réseau virtuel. L’essai s’appuyait sur les exemples standard d’éditeur et d’abonné GOOSE fournis avec la bibliothèque.
Les résultats ont montré qu’avec la version 1.6.2 les messages transmis arrivaient bien à l’interface réseau, mais que l’abonné n’appelait pas le gestionnaire de réception. Après application de la correction, les messages corrects ont commencé à être traités.
Le même jour, le mainteneur du projet, Michael Zillgith, a confirmé l’intégration de la correction et la publication de la version 1.6.2.1.
Ce que doivent faire les développeurs de produits basés sur libIEC61850
Pour les fabricants et les développeurs qui utilisent libIEC61850 dans leurs produits, la conclusion est directe : le bogue se trouve dans la bibliothèque et se retrouve dans tout produit compilé avec la version 1.6.2.
- Vérifier la version de la bibliothèque intégrée au produit — y compris dans les micrologiciels, les SDK, les composants tiers et les copies du code source reprises dans des dépôts internes.
- Passer à la 1.6.2.1 ou reporter la correction de la condition de contrôle de longueur dans la fonction
parseGooseMessagesi la bibliothèque a été modifiée en interne. - Tenir compte de sa propre entrée réseau. D’après le rapport de bogue, les trames transmises à la bibliothèque via
GooseReceiver_handleMessagene comportent pas d’octets de bourrage : toute trame peut donc être rejetée, et pas seulement celles de plus de 60 octets. - Ajouter des tests de non-régression sur la réception de trames GOOSE de différentes tailles : avec bourrage jusqu’à la longueur minimale de la trame Ethernet et sans bourrage.
- Publier une mise à jour pour les utilisateurs si un produit intégrant la version 1.6.2 a déjà été livré aux clients.
Ce que cela signifie pour les ingénieurs des postes numériques
Pour diagnostiquer un échange GOOSE, Wireshark est généralement l’un des premiers outils utilisés. Si le message figure dans la capture du trafic réseau, porte les adresses et identifiants attendus et que sa structure est correctement décodée, l’ingénieur peut supposer que le problème tient au paramétrage de l’abonnement ou à la logique de l’équipement récepteur.
Ce cas montre pourtant que la présence d’un message GOOSE correct dans une capture réseau ne garantit pas son traitement effectif par le logiciel applicatif.
Lors de la recherche de tels défauts, il importe de vérifier non seulement le passage des messages sur le réseau, mais aussi le fonctionnement du mécanisme logiciel d’abonnement : le message parvient-il à l’application, le gestionnaire GOOSE est-il appelé, la version de la bibliothèque utilisée présente-t-elle des bogues connus ?
Pour les systèmes basés sur libIEC61850, une attention particulière doit être portée à la version de la bibliothèque et aux messages de diagnostic du récepteur. Lors de la reproduction du défaut, il est utile de comparer le traitement des trames avec et sans octets de bourrage.
Conclusion
Le bogue de libIEC61850 1.6.2 est un exemple révélateur de défaut qui ne survient pas au niveau de la transmission des trames Ethernet, mais directement dans l’implémentation logicielle du protocole. Le problème a été corrigé dans la version 1.6.2.1, publiée le 24 septembre 2026. Les développeurs de produits IEC 61850 basés sur libIEC61850 ont intérêt à vérifier la version de la bibliothèque qu’ils utilisent et, si nécessaire, à la mettre à jour dans leurs produits.
La présence de ce bogue dans une bibliothèque open source ne signifie pas que les relais de protection industriels sont concernés : cela dépend de l’implémentation logicielle, de sa version et des modifications apportées par le fabricant.
Ce cas souligne l’importance d’une vérification de bout en bout de l’échange GOOSE — depuis la présence du message sur le réseau jusqu’à son traitement effectif par l’application réceptrice.