우리는 GOOSE 메시지(멀티캐스트 메시지, 일반 객체 지향 변전소 이벤트, IEC61850 프로토콜 표준의 일부) 구독 모듈을 구현하려고 합니다. 거의 모든 경우에 GOOSE 메시지를 지연 없이 읽을 수 있었습니다. 그러나 간헐적으로 GOOSE 메시지가 3초 지연된 후 애플리케이션에 도착합니다. 오류 상황에서 캡처된 PCAP 파일을 분석한 결과, GOOSE 메시지가 지연 없이 장치 네트워크 계층에 도달한 것을 확인했습니다.
recvfrom하위 계층에서 메시지를 가져오기 위해 호출을 사용합니다 .
리눅스 버전: linux-3.8.13
다음과 같이 전화에 응답하십시오.
unsigned char etherFrameRx[1518];
recvLen = recvfrom (hPktSock, etherFrameRx, sizeof(etherFrameRx),
MSG_TRUNC, NULL, NULL);
소켓은 다음과 같이 초기화됩니다.
hPktSock = socket (PF_PACKET, SOCK_RAW, htons(ETH_P_ALL);
arg |= O_NONBLOCK;
ret = fcntl (hPktSock, F_SETFL, arg);
지연(장치 MAC 계층에서 메시지를 수신한 후 애플리케이션이 메시지를 수신하는 데 걸리는 시간)이 기록되어 있지만 애플리케이션은 대상 MAC이 "모두 0"(0:0:0)인 프레임을 계속해서 수신합니다. :0:0:0) . 그리고 Wireshark 로그(eth0 인터페이스)에서는 이러한 메시지를 확인할 수 없습니다. 커널의 이러한 연속적인 예외 메시지는 GOOSE 수신을 지연시킵니다.
장치 시간이 동기화된 후에는 이 문제가 발생할 가능성이 더 높습니다. SNTP는 시간 동기화를 위한 메커니즘입니다.
Wireshark(GOOSE에 가입된 장치에 설치됨)를 사용하여 오류 상황에서 캡처된 .pcap 파일은 다음 경로에서 공유됩니다.
[사용 불가]
로그에는 12:36:11.636989에 GOOSE 메시지가 수신되었습니다. 그런데 앱의 업데이트 시간은 12:36:14.8012 입니다.
Linux 커널이 대상 MAC이 모두 0인 프레임을 반환하는 이유는 무엇입니까?