일부 WiFi 라우터가 유선에서 무선으로 이동하는 멀티 캐스트 패킷을 차단하는 이유는 무엇입니까?

일반적으로 Wi-Fi 홈 게이트웨이 라우터 (AP) 또는 무선 클라이언트 칩셋 / 드라이버 / 소프트웨어의 버그로 인해 발생합니다.

Wi-Fi에서 AP에서 무선 클라이언트로 멀티 캐스트를 전송하는 것은 까다롭기 때문에 실패 할 수있는 여러 가지 방법이 있습니다. 버그를 소개합니다.

1. 무선 매체는 802.11 유니 캐스트가 링크 수준 승인 (ACK)을 가져야하고 ACK가없는 경우 여러 번 재전송되어야 할만큼 충분히 신뢰할 수 없지만 모든 무선 클라이언트에서 승인해야하므로 FromDS 멀티 캐스트는 결코 ACK되지 않습니다. AP의 "ACK 폭풍"이 될 수 있습니다. 따라서 대신 FromDS 멀티 캐스트는 낮은 데이터 속도로 전송되어야합니다. AP의 모든 클라이언트가 안정적으로 수신 할 수있는 더 간단하고 느리고 디코딩하기 쉬운 낮은 신호 대 잡음비 변조 방식을 사용합니다. 일부 AP는 관리자가 멀티 캐스트 속도를 설정하도록 허용하고 일부 관리자는 일부 관리자가 자신도 모르게 너무 높게 설정하여 일부 클라이언트가 안정적으로 수신하지 못하도록하여 해당 클라이언트에 대한 멀티 캐스트 전달을 중단합니다.
2. WPA (TKIP) 또는 WPA2 (AES-CCMP) 암호화를 사용하는 경우 FromDS 멀티 캐스트는 모든 클라이언트에 알려진 별도의 암호화 키 (이를 그룹 키라고 함)로 암호화해야합니다.
3. 클라이언트가 네트워크를 떠날 때 또는 매시간마다 좋은 측정을 위해 그룹 키를 변경하여 남은 클라이언트가 더 이상 멀티 캐스트를 해독 할 수있는 액세스 권한을 갖지 않도록해야합니다. 이 "그룹 키 순환"프로세스에는 때때로 문제가 있습니다. 클라이언트가 새 그룹 키의 수신을 확인하지 않으면 AP는 해당 클라이언트의 인증을 해제해야하지만 버그로 인해 인증이 실패하면 클라이언트가 잘못된 그룹 키를 갖게되어 "귀머거리가 될 수 있습니다. "그것을 깨닫지 못한 채 멀티 캐스트에.
4. WPA2 "혼합 모드"가 활성화 된 경우 (즉, WPA와 WPA2가 동시에 활성화 된 경우) 일반적으로 FromDS 멀티 캐스트를 TKIP 암호로 인코딩해야 모든 클라이언트가 디코딩 방법을 알 수 있습니다. .
5. FromDS 멀티 캐스트는 AP에 의해 대기열에 추가되어야하며 멀티 캐스트에 관심이있는 모든 클라이언트가 수신기 전원을 켤 수있을 것으로 예상되는 시간에만 전송되어야합니다. "FromDS 멀티 캐스트 전송에 안전한"기간 사이의 시간을 "DTIM 간격"이라고합니다. AP 또는 클라이언트가 DTIM 간격 처리를 망칠 경우 클라이언트가 멀티 캐스트를 안정적으로 수신하지 못할 수 있습니다.
6. 일부 AP에는 무선 클라이언트가 서로 직접 통신하지 못하도록하여 무선 게스트가 다른 무선 게스트를 해킹하지 못하도록하는 기능이 있습니다. 이러한 기능은 일반적으로 WLAN 장치에서 다른 WLAN 장치로의 멀티 캐스트를 차단하며 LAN에서 WLAN으로의 멀티 캐스트도 차단하는 순진한 방식으로 구현 될 수 있습니다.

미친 점은 "ToDS"멀티 캐스트가 ToDS 유니 캐스트처럼 수행되므로 거의 중단되지 않는다는 것입니다. 그리고 ToDS 멀티 캐스트 (FromDS 멀티 캐스트가 아님)는 무선 클라이언트가 기본 게이트웨이를 찾기 위해 DHCP 임대 및 ARP를받을 때 필요한 모든 것이기 때문에 대부분의 클라이언트는 FromDS를 사용하는 경우에도 연결하여 웹 서핑, 이메일 확인 등을 할 수 있습니다. 멀티 캐스트가 깨졌습니다. 따라서 많은 사람들이 mDNS (일명 IETF ZeroConf, Apple Bonjour, Avahi 등)와 같은 작업을 시도 할 때까지 네트워크에서 멀티 캐스트 문제가 있다는 사실을 깨닫지 못합니다.

유선-무선 멀티 캐스트 전송과 관련하여 유의해야 할 몇 가지 다른 사항 :

1. mDNS와 같은 대부분의 LAN 멀티 캐스트는 라우터를 통해 라우팅되지 않는 특수 멀티 캐스트 주소 범위를 사용하여 수행됩니다. NAT가 활성화 된 Wi-Fi 가능 홈 게이트웨이는 라우터로 간주되므로 mDNS는 WAN에서 [W] LAN으로 교차하는 것을 의미하지 않습니다. 그러나 LAN에서 WLAN으로 작동해야합니다.
2. Wi-Fi의 멀티 캐스트는 낮은 데이터 속도로 전송되어야하기 때문에 많은 방송 시간을 차지합니다. 그래서 그들은 "비싸고", 당신은 그것들을 너무 많이 갖고 싶지 않습니다. 이는 예를 들어 "멀티 캐스트 비디오 스트림으로 튜닝"하는 각 시스템에 별도의 유니 캐스트를 보내는 것보다 멀티 캐스트가 "저렴"한 유선 이더넷에서 작동하는 방식과 반대입니다. 이 때문에 많은 Wi-Fi AP는 "IGMP 스누핑"을 수행하여 어떤 컴퓨터가 IGMP (Internet Group Management Protocol) 요청을 보내는 지 확인하여 주어진 멀티 캐스트 스트림에 맞추고 자하는 의사를 표현합니다. IGMP 스누핑을 수행하는 Wi-Fi AP는 무선 클라이언트가 IGMP를 통해 해당 스트림에 가입을 시도하지 않는 한 일부 클래스의 멀티 캐스트를 무선 네트워크로 자동으로 전달하지 않습니다. IGMP 스누핑을 올바르게 수행하는 방법을 설명하는 문서는 저 대역폭 멀티 캐스트 (mDNS가이 범주에 해당)의 특정 클래스가 IGMP를 통해 명시 적으로 요청하지 않은 경우에도 항상 전달되어야 함을 분명히합니다. 그러나 IGMP 요청을 볼 때까지 어떤 종류의 멀티 캐스트도 절대로 전달하지 않는 깨진 IGMP 스누핑 구현이 있다고해도 놀라지 않을 것입니다.

tl; dr : 버그. 버그에 대한 많은 기회. 그리고 가끔 잘못 설계된 기능과 구성 오류. 최선의 방어책은 멀티 캐스트가 작동하는지 확인하는 데 관심이있는 회사에서 고품질 AP를 구입하는 것입니다. Apple은 Bonjour (mDNS)를 매우 좋아하기 때문에 Apple의 AP는 아마도 멀티 캐스트를 안정적으로 전달하는 데 가장 일관되게 우수 할 것이며 Apple의 Wi-Fi 클라이언트 장치는 멀티 캐스트를 안정적으로 수신하는 데 가장 일관되게 우수 할 것입니다.