El 24 de septiembre de 2026, los desarrolladores de la biblioteca de código abierto libIEC61850 publicaron la versión 1.6.2.1, que corrige un error en el mecanismo de recepción de mensajes GOOSE. La corrección está relacionada con el problema n.º 603, registrado en el repositorio del proyecto el 24 de julio de 2026.
Esto afecta, ante todo, a los desarrolladores de productos compatibles con la norma IEC 61850 que utilizan libIEC61850: dispositivos, pasarelas, controladores, sistemas de software y software de pruebas. Si un producto incorporó la versión 1.6.2, publicada el 23 de julio de 2026, la recepción de GOOSE puede fallar ya en las instalaciones de los usuarios finales, aunque el intercambio en la red parezca correcto.
Para los ingenieros de protección y control, el caso es ilustrativo porque muestra una situación en la que la comunicación de red funciona correctamente, pero el software de aplicación no procesa los mensajes recibidos.
¿En qué consistía el error?
Según IEC 61850-8-1, los mensajes GOOSE se transmiten directamente en tramas Ethernet. La cabecera GOOSE incluye el campo Length, que indica la longitud del mensaje, incluidos los campos de cabecera GOOSE y el bloque de datos APDU.
Al recibir una trama, la biblioteca libIEC61850 comprueba que la longitud real de la trama recibida corresponda al valor indicado en la cabecera.
En la versión 1.6.2 apareció un error en esta comprobación: las tramas cuya longitud real coincidía exactamente con la declarada se consideraban, por error, incorrectas.
La causa fue el cambio de un único operador de comparación en la función parseGooseMessage. En lugar de la condición:
numbytes < length + headerLength
se utilizaba la condición:
numbytes <= length + headerLength
Aquí numbytes es el número de bytes realmente recibidos, headerLength es la longitud de la cabecera Ethernet (14 bytes, o 18 con etiqueta VLAN) y length es el valor del campo Length de la cabecera GOOSE. La suma length + headerLength es la longitud que debe tener la trama según su propia cabecera.
La comprobación correcta descarta una trama solo si se han recibido menos bytes de los indicados en la cabecera, es decir, si la trama está truncada. La errónea la descartaba también cuando se recibían exactamente los bytes indicados. Pero así es precisamente una trama normal, sin bytes sobrantes al final.
La biblioteca consideraba dañada una trama así y la descartaba antes incluso de comprobar si alguno de los suscriptores configurados estaba suscrito a ella. Con el diagnóstico activado se mostraba el error «Invalid PDU size».
¿Por qué unos mensajes GOOSE se recibían y otros no?
Una trama Ethernet no puede tener menos de 64 bytes, o 60 bytes sin la suma de comprobación FCS. Si el mensaje GOOSE es más corto, el dispositivo emisor añade al final de la trama bytes de relleno (padding). Estos bytes no se incluyen en el valor del campo Length.
Por ejemplo, si según su cabecera una trama debe ocupar 44 bytes, se rellenará hasta 60. La biblioteca recibe 60 bytes —más de los indicados en la cabecera— y la comprobación errónea se cumple. Una trama así se aceptaba.
Si, en cambio, la trama ocupa 60 bytes o más sin relleno, no hay nada que añadir: se reciben exactamente los bytes indicados en la cabecera. En el ejemplo del informe del error, esa trama tiene 111 bytes. Son precisamente estas tramas las que la versión 1.6.2 descartaba. Como señala el autor del informe, es el caso habitual con conjuntos de datos reales: el error afectaba a todas las tramas GOOSE más largas que la trama Ethernet mínima.
Así, la recepción de GOOSE dependía de la longitud de la trama y de la presencia de bytes de relleno, aunque el mensaje en sí fuera correcto.
¿Cómo se descubrió el problema?
El autor del informe del error preparó un ejemplo reproducible con una trama GOOSE de 111 bytes. Con libIEC61850 1.6.2, el mensaje no llegaba al manejador del suscriptor. Tras corregir la condición de comprobación, la misma trama se recibía correctamente.
El 24 de septiembre, otro participante del proyecto publicó los resultados de una comprobación independiente con dos contenedores Linux conectados por una red virtual. En la prueba se utilizaron los ejemplos estándar de publicador y suscriptor GOOSE incluidos en la biblioteca.
Los resultados mostraron que, con la versión 1.6.2, los mensajes transmitidos llegaban a la interfaz de red, pero el suscriptor no invocaba el manejador de recepción. Tras aplicar la corrección, los mensajes correctos empezaron a procesarse.
Ese mismo día, el responsable del proyecto, Michael Zillgith, confirmó la incorporación de la corrección y la publicación de la versión 1.6.2.1.
Qué deben hacer los desarrolladores de productos basados en libIEC61850
Para los fabricantes y desarrolladores que utilizan libIEC61850 en sus productos, la conclusión es directa: el error está en la biblioteca y se traslada a todo producto compilado con la versión 1.6.2.
- Comprobar la versión de la biblioteca incluida en el producto, también en el firmware, los SDK, los componentes de terceros y las copias del código fuente trasladadas a repositorios propios.
- Actualizar a la 1.6.2.1 o trasladar la corrección de la condición de comprobación de longitud en la función
parseGooseMessagesi la biblioteca se ha modificado internamente. - Tener en cuenta la entrada de red propia. Según el informe del error, las tramas entregadas a la biblioteca mediante
GooseReceiver_handleMessageno llevan bytes de relleno, por lo que puede descartarse cualquier trama, no solo las de más de 60 bytes. - Añadir pruebas de regresión de recepción de tramas GOOSE de distintos tamaños: con relleno hasta la longitud mínima de la trama Ethernet y sin él.
- Publicar una actualización para los usuarios si un producto con la versión 1.6.2 ya se ha entregado a clientes.
Qué significa esto para los ingenieros de subestaciones digitales
Al diagnosticar el intercambio GOOSE, Wireshark suele ser una de las primeras herramientas. Si el mensaje aparece en la captura del tráfico de red, tiene las direcciones e identificadores esperados y su estructura se decodifica correctamente, el ingeniero puede suponer que el problema está en la configuración de la suscripción o en la lógica del dispositivo receptor.
Sin embargo, este caso demuestra que la presencia de un mensaje GOOSE correcto en una captura de red no garantiza que el software de aplicación lo procese con éxito.
Al buscar este tipo de fallos, es importante comprobar no solo el paso de los mensajes por la red, sino también el funcionamiento del mecanismo de suscripción del software: si el mensaje llega a la aplicación, si se invoca el manejador GOOSE y si la versión de la biblioteca utilizada contiene errores conocidos.
En los sistemas basados en libIEC61850 conviene prestar especial atención a la versión de la biblioteca y a los mensajes de diagnóstico del receptor. Al reproducir el fallo, resulta útil comparar el procesamiento de tramas con y sin bytes de relleno.
Conclusión
El error de libIEC61850 1.6.2 es un ejemplo ilustrativo de un fallo que no surge en la transmisión de tramas Ethernet, sino directamente en la implementación de software del protocolo. El problema se corrigió en la versión 1.6.2.1, publicada el 24 de septiembre de 2026. Los desarrolladores de productos IEC 61850 basados en libIEC61850 deberían comprobar la versión de la biblioteca que utilizan y, si es necesario, actualizarla en sus productos.
La presencia de este error en una biblioteca de código abierto no significa que los relés de protección industriales estén afectados: depende de la implementación de software, de su versión y de las modificaciones realizadas por el fabricante.
Este caso subraya la importancia de verificar de forma integral el intercambio GOOSE: desde la presencia del mensaje en la red hasta su procesamiento real por la aplicación receptora.