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

나는 수십 개의 소비자 급 WiFi 라우터와 함께 일해 왔는데, 점점 좋아질 것 같지만 실제로 이것에 맞지 않았습니다.

문제의 예 :

1. mDNS로 검색 할 수있는 장치는 케이블을 사용하여 라우터에 연결됩니다.
2. WiFi의 라우터에 연결된 다른 장치는 1 단계에서 장치 검색을 시도합니다.
3. WiFi의 장치에서 보낸 패킷은 유선 장치로 전달되지 않거나 유선 장치에서 보낸 패킷이 무선 장치로 전달되지 않습니다.

많은 라우터에는이 기능이 작동하도록 설정되어 있습니다.

http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 및 http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired를 참조 하십시오 및 무선 네트워크 onactiontec / td-p / 461359 예를 들어.

이것과 호환되지 않는 목록이 있습니까? 원인이 무엇입니까? 라우터에 버그가 있습니까?

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

Wi-Fi에서는 AP에서 무선 클라이언트로 멀티 캐스트를 보내는 것이 쉽지 않습니다 ( "배포 시스템에서"또는 "FromDS"로 표준에 알려져 있음). 실패 할 수있는 여러 가지 방법이 있으며 버그를 소개합니다.

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

"ToDS"멀티 캐스트는 ToDS 유니 캐스트와 마찬가지로 수행되므로 거의 중단되지 않습니다. 또한 무선 클라이언트가 DHCP 임대 및 ARP를 통해 기본 게이트웨이를 찾을 때 ToDS 멀티 캐스트 (FromDS 멀티 캐스트가 아님) 만 있으면되므로 대부분의 클라이언트는 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 스누핑을 수행하는 방법을 설명하는 문서는 IGMP를 통해 명시 적으로 요청한 사람이 없더라도 특정 저 대역폭 멀티 캐스트 클래스 (mDNS가이 범주에 적합 함)가 항상 전달되어야 함을 명확하게 보여줍니다. 그러나 IGMP 요청을 볼 때까지 절대로 어떤 종류의 멀티 캐스트도 전달하지 않는 IGMP 스누핑 구현이 깨진 경우 놀라지 않을 것입니다.

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

@Spiff는 그의 대답에서 멋진 점을 지적했으며 여기에서 반복하지 않습니다. 그러나이 문제를 해결하기위한 다른 답변과 대안이 있습니다.

짧은 답변? 나는 특정 장치를 만드는 엔지니어 게으름 때문에 항상 "시작하지 않는"만큼 항상 "차단"한다고 생각하지 않습니다. 일부는 우선 순위가 높지 않으며 일부는 작동 할 시간이 없습니다.

그것은 소비자 등급 장치를 판매하기 위해 사용하는 모든 새로운 "기능"마케팅과 비교할 때 우선 순위 목록에서 높지 않으며 대부분의 기술에 정통하지 않은 사람들이 알지 못하는 기능이므로 우선 순위 목록을 아래로 내려갈 때까지 다수의 소유자 풀이 이에 대해 불평하지 않는 한 개정 업데이트에서 제외됩니다.

당신이 그것을 지원하는 장치를 원한다면, 당신의 연구에 대한 실사를 수행하고 그것을 지원하는 장치를 얻 거나 , Polarcloud에서 OpenWrt 또는 Tomato 와 같은 것을 지원하는 새로운 장치 나 중고 장치를 찾을 수 있다면 필요한 것을 얻을 수 있습니다.

행운을 빕니다. :)