2개의 네트워크 카드에 대한 "합법적인" ARP 중독을 집계하면 충돌이 발생합니다.

이상한 일이 일어나고 있고, 위협이 나타나고 있습니다. 우리는 이를 해결해야 합니다.

상태:

우리 장치(네트워크 카메라)는 네트워크를 통해 비디오를 레코더/서버(Live555/WIS Streamer 사용)로 스트리밍합니다. 비디오는 UDP 패킷입니다.

특정 서버를 사용하는 특정 사이트에서는 비디오를 보내는 동안 Live555 스트리밍의 한 스레드가 가끔씩(약 24시간) 잠기곤 했습니다. 다른 스레드는 계속 실행되며 IP를 통해 카메라에 계속 연결할 수 있습니다(웹 페이지 보기, PING 등).

우리는 의심한다: 서버; 2개의 네트워크 포트가 있고 이를 통합합니다. MAC은 2개이지만 IP 주소는 1개입니다. 와이어쉐이킹하는 동안 카메라가 한 포트(A라고 칭함)로 흐르는 것을 본 다음 다른 포트(B라고 칭함)에서 ARP를 얻고 장치는 MAC A에 패킷을 스프레이하는 라인을 중지하고 MAC에 패킷을 스프레이합니다. B 그러다가 멈춘 것 같다.

추가 정보: 서버는 잘못된 구성 등으로 인해 "잘못된" 포트에서 들어오는 ARP 패킷을 손상시킨 것으로 보입니다. 그러나 이러한 패킷은 드라이버 또는 커널 네트워크 구성 오류로 인해 장치에서 여전히 읽고 작동합니다. 또는 체크섬 건너뛰기 CPU 사이클을 절약하세요.

따라서 이 혼란스러운 상황은 몇 가지 질문을 제기합니다.

1. 커널 네트워크 코드의 어디에서 패킷 체크섬을 확인하거나 확인을 활성화해야 합니까? 우리의 하드웨어는 고정되어 있고 내장형 장치이므로 드라이버를 조정하는 것이 최악의 생각은 아닙니다.
2. send()프로세스가 포트에서 계속 데이터를 가져오고 ARP 테이블이 그 아래로 이동할 때 프로세스가 잠기는 실패 메커니즘을 추측할 수 있는 사람이 있습니까?

추가하려면 수정하세요.: 이제 우리는 ARP가 실제로 손상된 것이 아니라고 의심합니다. 이는 Wireshark가 패킷을 올바르게 식별하지 못하는 것일 뿐입니다(패킷이 FSC 단어를 포함할 만큼 충분히 길다고 생각하지만 지금은 단지 제로 패딩이라고 생각합니다). 이제 질문의 두 번째 부분만 남습니다. ARP 테이블의 이러한 변경으로 인해 전송 프로세스가 중단되는 것을 방지하려면 어떻게 해야 할까요?

추가 내용을 편집하여 다음을 추가했습니다.사람들이 내가 포트 상태 또는 프로세스 상태와 관련된 문제를 무시하고 있다고 생각하기를 원하지 않습니다. 이 문제는 매우 드물게 발생하며(평균 24시간에 한 번) 우리가 보유하지 않은 하나의 (원격) 설치에서만 발생합니다. 더 자세한 진단을 위해 연구실에 복제하는 작업 중이지만 시스템 감시는 문제 발생 후 약 3분 후에 재설정되므로 메시지를 받을 때쯤에는 이미 재부팅되어 시작된 것입니다. 정상적으로 작동합니다.

Wireshark 정보를 추가하려면 편집하세요.:여기서 Wireshark 캡처를 요약하는 가장 좋은 방법은 잘 모르겠지만(~1Tb 캡처 패킷을 업로드하는 것은 어렵습니다!) 시도해 보겠습니다. Cam:X& Cam:Y는 두 개의 동일한 Live555 WIS Streamer 인스턴스에 의해 서로 다른 포트에서 전송되는 두 개의 RTSP 비디오 스트림입니다. 서버 "A"와 "B"는 서버에 있는 두 네트워크 카드의 MAC입니다.

패킷의 순서는 다음과 같습니다.

UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'

이 지점이나 그 근처에는 스트림에 다른 패킷이 없습니다. Intel ANS 패킷이 NIC에서 오는 ARP와 항상 일치하는 것은 아니지만 완전성을 위해 이를 포함하고 싶었습니다.

문제는 매우 시간에 민감한 것 같습니다. 우리는 정기적으로 서버에서 이러한 "팀" ARP를 확인하며 단 한 번만 문제를 일으킵니다. 마치 네트워크 스택 코드에 ARP 테이블을 변경한 특정 지점이 있는 것처럼 보입니다. . 특히 다른 인스턴스(및 기타 모든 네트워크 트래픽(HTTP 등))가 계속해서 정상적으로 작동하기 때문에 실패한 흐름 인스턴스가 항상 동일하지는 않습니다.

팀으로 구성된 NIC는 이 세션에서와 같이 ARP를 "해서는 안 되는" 것처럼 들리지만 트래픽이 모두 UDP인 경우에는 어떤 세션도 알 수 없습니다.