On 24 September 2026, the developers of the open-source libIEC61850 library released version 1.6.2.1, which fixes a bug in the GOOSE message reception mechanism. The fix relates to issue No. 603, registered in the project repository on 24 July 2026.
This concerns, above all, developers of products supporting the IEC 61850 standard that use libIEC61850: devices, gateways, controllers, software systems and test software. If version 1.6.2, released on 23 July 2026, made its way into a product, GOOSE reception may break at the end users' sites — even though the exchange itself looks healthy on the network.
For protection, automation and control engineers, the case is instructive because it shows a situation in which network communication works correctly but the application software does not process the messages it receives.
What was the bug?
Under IEC 61850-8-1, GOOSE messages are carried directly in Ethernet frames. The GOOSE header contains a Length field that specifies the length of the message, including the GOOSE header fields and the APDU data block.
When a frame is received, the libIEC61850 library checks that the actual length of the received frame matches the value given in the header.
In version 1.6.2, a bug crept into this check: frames whose actual length exactly matched the declared length were wrongly treated as invalid.
The cause was a change to a single comparison operator in the parseGooseMessage function. Instead of the condition:
numbytes < length + headerLength
the following condition was used:
numbytes <= length + headerLength
Here numbytes is the number of bytes actually received, headerLength is the length of the Ethernet header (14 bytes, or 18 with a VLAN tag), and length is the value of the Length field in the GOOSE header. The sum length + headerLength is the length the frame should have according to its own header.
The correct check discards a frame only if fewer bytes have been received than the header states — that is, if the frame is truncated. The faulty check also discarded it when exactly as many bytes had been received as stated. But that is precisely what an ordinary frame looks like when there are no extra bytes at its end.
The library treated such a frame as corrupted and discarded it before even checking whether any of the configured subscribers had subscribed to it. With diagnostics enabled, an "Invalid PDU size" error was printed.
Why were some GOOSE messages accepted and others not?
An Ethernet frame cannot be shorter than 64 bytes, or 60 bytes without the FCS checksum. If a GOOSE message is shorter, the sending device appends padding bytes to the end of the frame. They are not included in the value of the Length field.
For example, if according to its header a frame should occupy 44 bytes, it will be padded to 60. The library receives 60 bytes — more than the header states — and the faulty check is satisfied. Such a frame was accepted.
If, however, the frame occupies 60 bytes or more without padding, there is nothing to add: exactly as many bytes are received as the header states. In the example from the bug report, such a frame is 111 bytes long. These are precisely the frames that version 1.6.2 discarded. As the author of the bug report notes, this is the normal case for real-world datasets: every GOOSE frame longer than the minimum Ethernet frame was affected.
Thus, whether a GOOSE message was received depended on the frame length and the presence of padding bytes, even though the message itself was valid.
How was the problem found?
The author of the bug report prepared a reproducible example with a 111-byte GOOSE frame. With libIEC61850 1.6.2, the message did not reach the subscriber's handler. After the check condition was corrected, the same frame was received successfully.
On 24 September, another project contributor published the results of an independent test using two Linux containers connected by a virtual network. The test used the standard GOOSE publisher and subscriber examples that ship with the library.
The results showed that with version 1.6.2 the transmitted messages arrived at the network interface, but the subscriber did not call the receive handler. After the fix was applied, valid messages began to be processed.
On the same day, project maintainer Michael Zillgith confirmed that the fix had been merged and that version 1.6.2.1 had been released.
What developers of products based on libIEC61850 should do
For manufacturers and developers who use libIEC61850 in their products, the conclusion is straightforward: the bug is in the library and carries over into every product built with version 1.6.2.
- Check the library version in the product — including in embedded firmware, SDKs, third-party components and copies of the source code carried over into in-house repositories.
- Update to 1.6.2.1, or port the fix to the length check condition in the
parseGooseMessagefunction if the library has been modified in-house. - Take your own network input into account. According to the bug report, frames passed to the library via
GooseReceiver_handleMessagecarry no padding bytes, so every frame may be discarded, not only frames longer than 60 bytes. - Add regression tests for receiving GOOSE frames of different sizes: with padding up to the minimum Ethernet frame length and without it.
- Release an update for users if a product with version 1.6.2 has already been delivered to customers.
What this means for digital substation engineers
When diagnosing GOOSE communication, Wireshark is usually one of the first tools to hand. If a message is present in the traffic capture, has the expected addresses and identifiers, and its structure decodes correctly, an engineer may assume that the problem lies in the subscription settings or in the logic of the receiving device.
However, this case shows that the presence of a valid GOOSE message in a network capture does not guarantee that the application software processes it successfully.
When troubleshooting such faults, it is important to check not only that messages pass through the network but also how the software subscription mechanism works: whether the message reaches the application, whether the GOOSE handler is called, and whether the library version in use has any known bugs.
For systems based on libIEC61850, particular attention should be paid to the library version and the receiver's diagnostic messages. When reproducing the fault, it is useful to compare how frames with and without padding bytes are processed.
Conclusion
The libIEC61850 1.6.2 bug is a telling example of a fault that arises not at the level of Ethernet frame transmission but directly in the software implementation of the protocol. The problem was fixed in version 1.6.2.1, released on 24 September 2026. Developers of IEC 61850 products based on libIEC61850 should check which version of the library they use and, if necessary, update it in their products.
The presence of this bug in an open-source library does not mean that industrial protection relays are affected: that depends on the software implementation, its version and any changes made by the manufacturer.
This case highlights the importance of end-to-end verification of GOOSE communication — from the presence of a message on the network to its actual processing by the receiving application.