Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Delay in GOOSE Subscription

Hello All,

We are trying to implement GOOSE message(a multicast message, Generic Object Oriented Substation Event, part of IEC61850 protocol standard.) subscription Module. In almost all cases, we are able to read GOOSE messages without any delay. But intermittently, GOOSE messages are reaching in application after a delay of 3 sec. When analysed the pcap(PCAP file) file, captured during the error situation , it is noted that the GOOSE message is reaching upto the device Network layer without any delay.

We are using 'recvfrom' call to fetch the messages from sub layer.

Linux Version : linux-3.8.13

Receive call is as follows :

*unsigned char etherFrameRx[1518];

recvLen = recvfrom (hPktSock, etherFrameRx, sizeof(etherFrameRx), MSG_TRUNC, NULL, NULL);*

Socket initialization is as follows:

*hPktSock = socket (PFPACKET, SOCKRAW, htons(ETHPALL);

arg |= O_NONBLOCK;

ret = fcntl (hPktSock, F_SETFL, arg)*

While the delay is noticed, (Time between the message reception at device MAC layer and message reception at application), the 'recvfrom' call returns error code 'EAGAIN'. The probability of the issue occurrence is high after a time synchronization of the device. SNTP is the mechanism used for Time Synchronization.

The .pcap file captured using Wireshark (Installed on the device Subscribing the GOOSE) during error situation is shared at following path.

https://www.dropbox.com/s/ctcou2itusoyerr/GOOSE.zip?dl=0

In the log, the GOOSE message is received at 12:36:11.636989. But the same is updated on Application at 12:36:14.8012

What could be the reason of returning error code EAGAIN for recvfrom call, even with the pending messages at device sub layer? How is it implemented in 'pcap', anything that we could re use in our application? I could also see other messages as displayed(ARP etc)before the GOOSE, that could delay the GOOSE read?

Delay in GOOSE Subscription

Hello All,

We are trying to implement GOOSE message(a multicast message, Generic Object Oriented Substation Event, part of IEC61850 protocol standard.) subscription Module. In almost all cases, we are able to read GOOSE messages without any delay. But intermittently, GOOSE messages are reaching in application after a delay of 3 sec. When analysed the pcap(PCAP file) file, captured during the error situation , it is noted that the GOOSE message is reaching upto the device Network layer without any delay.

We are using 'recvfrom' call to fetch the messages from sub layer.

Linux Version : linux-3.8.13

Receive call is as follows :

*unsigned unsigned char etherFrameRx[1518];

etherFrameRx[1518]; recvLen = recvfrom (hPktSock, etherFrameRx, sizeof(etherFrameRx), MSG_TRUNC, NULL, NULL);*NULL);

Socket initialization is as follows:

*hPktSock hPktSock = socket (PFPACKET, SOCKRAW, htons(ETHPALL);

(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL); arg |= O_NONBLOCK;

O_NONBLOCK; ret = fcntl (hPktSock, F_SETFL, arg)*arg)

While the delay is noticed, (Time between the message reception at device MAC layer and message reception at application), the 'recvfrom' call returns error code 'EAGAIN'. The probability of the issue occurrence is high after a time synchronization of the device. SNTP is the mechanism used for Time Synchronization.

The .pcap file captured using Wireshark (Installed on the device Subscribing the GOOSE) during error situation is shared at following path.

https://www.dropbox.com/s/ctcou2itusoyerr/GOOSE.zip?dl=0

In the log, the GOOSE message is received at 12:36:11.636989. But the same is updated on Application at 12:36:14.8012

What could be the reason of returning error code EAGAIN for recvfrom call, even with the pending messages at device sub layer? How is it implemented in 'pcap', anything that we could re use in our application? I could also see other messages as displayed(ARP etc)before the GOOSE, that could delay the GOOSE read? read?

Delay in GOOSE Subscription

Hello All,

We are trying to implement GOOSE message(a multicast message, Generic Object Oriented Substation Event, part of IEC61850 protocol standard.) subscription Module. In almost all cases, we are able to read GOOSE messages without any delay. But intermittently, GOOSE messages are reaching in application after a delay of 3 sec. When analysed the pcap(PCAP file) file, captured during the error situation , it is noted that the GOOSE message is reaching upto the device Network layer without any delay.

We are using 'recvfrom' call to fetch the messages from sub layer.

Linux Version : linux-3.8.13

Receive call is as follows :

unsigned *unsigned char etherFrameRx[1518]; etherFrameRx[1518];

recvLen = recvfrom (hPktSock, etherFrameRx, sizeof(etherFrameRx), MSG_TRUNC, NULL, NULL);NULL);*

Socket initialization is as follows:

hPktSock = socket (PF_PACKET, SOCK_RAW, htons(ETH_P_ALL); arg |= O_NONBLOCK; ret = fcntl (hPktSock, F_SETFL, arg)

While the delay is noticed, (Time between the message reception at device MAC layer and message reception at application), the 'recvfrom' call returns error code 'EAGAIN'. The probability of the issue occurrence is high after a time synchronization of the device. SNTP is the mechanism used for Time Synchronization.

The .pcap file captured using Wireshark (Installed on the device Subscribing the GOOSE) during error situation is shared at following path.

https://www.dropbox.com/s/ctcou2itusoyerr/GOOSE.zip?dl=0

In the log, the GOOSE message is received at 12:36:11.636989. But the same is updated on Application at 12:36:14.8012

What could be the reason of returning error code EAGAIN for recvfrom call, even with the pending messages at device sub layer? How is it implemented in 'pcap', anything that we could re use in our application? I could also see other messages as displayed(ARP etc)before the GOOSE, that could delay the GOOSE read?

Delay in GOOSE Subscription

Hello All,

We are trying to implement GOOSE message(a multicast message, Generic Object Oriented Substation Event, part of IEC61850 protocol standard.) subscription Module. In almost all cases, we are able to read GOOSE messages without any delay. But intermittently, GOOSE messages are reaching in application after a delay of 3 sec. When analysed the pcap(PCAP file) file, captured during the error situation , it is noted that the GOOSE message is reaching upto the device Network layer without any delay.

We are using 'recvfrom' call to fetch the messages from sub layer.

Linux Version : linux-3.8.13

Receive call is as follows :

*unsigned unsigned char etherFrameRx[1518];

recvLen = recvfrom (hPktSock, etherFrameRx, sizeof(etherFrameRx), MSG_TRUNC, NULL, NULL);*NULL);

Socket initialization is as follows:

hPktSock = socket (PF_PACKET, SOCK_RAW, htons(ETH_P_ALL); (PFPACKET, SOCKRAW, htons(ETHPALL);

arg |= O_NONBLOCK; O_NONBLOCK;

ret = fcntl (hPktSock, F_SETFL, arg)arg);

While the delay is noticed, (Time between the message reception at device MAC layer and message reception at application), the 'recvfrom' call returns error code 'EAGAIN'. The probability of the issue occurrence is high after a time synchronization of the device. SNTP is the mechanism used for Time Synchronization.

The .pcap file captured using Wireshark (Installed on the device Subscribing the GOOSE) during error situation is shared at following path.

https://www.dropbox.com/s/ctcou2itusoyerr/GOOSE.zip?dl=0

In the log, the GOOSE message is received at 12:36:11.636989. But the same is updated on Application at 12:36:14.8012

What could be the reason of returning error code EAGAIN for recvfrom call, even with the pending messages at device sub layer? How is it implemented in 'pcap', anything that we could re use in our application? I could also see other messages as displayed(ARP etc)before the GOOSE, that could delay the GOOSE read?