Tại sao một số bộ định tuyến WiFi chặn các gói phát đa hướng đi từ có dây sang không dây?


26

Tôi đã làm việc với hàng tá bộ định tuyến WiFi cấp độ người tiêu dùng và họ đã thực sự gặp phải vấn đề này, mặc dù nó có vẻ đang trở nên tốt hơn.

Ví dụ về vấn đề:

  1. Một thiết bị có thể được phát hiện với mDNS được kết nối với bộ định tuyến bằng cáp.
  2. Một thiết bị khác được kết nối với bộ định tuyến trên WiFi cố gắng khám phá thiết bị ở bước 1.
  3. Các gói từ thiết bị trên WiFi không chuyển đến thiết bị có dây hoặc nếu có, các gói được gửi từ thiết bị có dây sẽ không chuyển đến thiết bị không dây.

Nhiều bộ định tuyến có cài đặt cho phép điều này hoạt động.

Xem http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -và không dây-mạng-trên-actiontec / td-p / 461359 chẳng hạn.

Có một danh sách bất cứ nơi nào không tương thích với điều này? Nguyên nhân là gì? Chỉ là một lỗi trong bộ định tuyến?


1
Điều này có thể sẽ được chuyển sang Superuser - họ giao dịch nhiều hơn với các thiết bị cấp tiêu dùng ở đó.
EEAA

Câu trả lời:


40

Điều này thường do lỗi trong các bộ định tuyến cổng nhà (AP) Wi-Fi hoặc đôi khi trong các chipset / trình điều khiển / phần mềm máy khách không dây.

Trên Wi-Fi, việc gửi đa tuyến từ AP đến các máy khách không dây (điều này được biết đến trong tiêu chuẩn là "Từ hệ thống phân phối" hoặc "FromDS") rất khó khăn, vì vậy có rất nhiều cách có thể thất bại và rất dễ để giới thiệu lỗi.

  1. Mặc dù phương tiện vô tuyến không đủ tin cậy để unicasts 802.11 được yêu cầu phải có xác nhận cấp liên kết (ACK) và được truyền lại nhiều lần nếu không có ACK, các đa tuyến FromDS không bao giờ bị ACKed bởi vì chúng cần phải được ACKed bởi tất cả các máy khách không dây của AP, có thể là một "cơn bão ACK". Vì vậy, thay vào đó, các multicast FromDS phải được gửi ở tốc độ dữ liệu thấp; sử dụng một sơ đồ điều chế tỷ lệ đơn giản, chậm, dễ giải mã-thậm chí ở mức thấp tín hiệu-nhiễu-nhiễu, có thể được tất cả các khách hàng của AP tin cậy. Một số AP cho phép quản trị viên đặt tốc độ phát đa hướng và một số quản trị viên vô tình đặt mức quá cao để một số khách hàng của họ nhận được một cách đáng tin cậy, phá vỡ phân phối phát đa hướng cho các khách hàng đó.
  2. Khi sử dụng mã hóa WPA (TKIP) hoặc WPA2 (AES-CCMP), các đa hướng FromDS phải được mã hóa bằng một khóa mã hóa riêng biệt được biết đến cho tất cả các máy khách (đây được gọi là Khóa nhóm).
  3. Khi một máy khách rời khỏi mạng, hoặc mỗi giờ hoặc lâu hơn, chỉ để có biện pháp tốt, Khóa nhóm cần được thay đổi để máy khách không còn quyền truy cập để giải mã đa tuyến. Quá trình "Xoay vòng khóa nhóm" này đôi khi có vấn đề. Nếu khách hàng không xác nhận đã nhận khóa nhóm mới, AP có nghĩa vụ phải xác thực lại ứng dụng khách đó, nhưng nếu không thực hiện được do lỗi, khách hàng có thể có khóa nhóm sai và do đó bị "điếc "Để đa hướng mà không nhận ra nó.
  4. Khi WPA2 "chế độ hỗn hợp" được bật (nghĩa là khi cả WPA và WPA2 được bật cùng lúc), các đa tuyến FromDS thường phải được mã hóa bằng mật mã TKIP, để tất cả các máy khách được đảm bảo biết cách giải mã nó .
  5. Các multicast của FromDS phải được xếp hàng bởi AP và chỉ được truyền vào những thời điểm mà tất cả các khách hàng quan tâm đến đa hướng có thể được yêu cầu bật máy thu của họ. Khoảng thời gian giữa các khoảng thời gian "an toàn để truyền FromDS" được gọi là "khoảng DTIM". Nếu AP hoặc máy khách làm hỏng việc xử lý khoảng DTIM của họ, điều đó có thể dẫn đến việc khách hàng không thể nhận được tín hiệu đa hướng một cách đáng tin cậy.
  6. Một số AP có các tính năng để giữ cho các máy khách không dây có thể nói chuyện trực tiếp với nhau, để có thể giữ cho khách không dây của bạn không hack các khách không dây khác của bạn. Các tính năng này thường chặn đa tuyến từ thiết bị WLAN đến các thiết bị WLAN khác và cũng có thể được triển khai theo cách ngây thơ, thậm chí chặn đa tuyến từ LAN sang WLAN.

Điều điên rồ là, các đa hướng "ToDS" được thực hiện giống như các đơn vị ToDS, và vì vậy chúng hiếm khi bị phá vỡ. Và vì các đa hướng ToDS (không phải là các đa hướng FromDS) là tất cả những gì cần thiết khi máy khách không dây nhận được hợp đồng thuê DHCP và ARP để tìm cổng mặc định của nó, hầu hết các máy khách đều có thể kết nối và lướt web, kiểm tra email, v.v. ngay cả khi FromDS đa hướng bị hỏng. Vì vậy, nhiều người không nhận ra rằng họ có vấn đề phát đa hướng trên mạng cho đến khi họ cố gắng thực hiện những việc như mDNS (còn gọi là IETF ZeroConf, Apple Bonjour, Avahi, v.v.).

Một vài điều khác cần lưu ý, liên quan đến truyền phát đa tuyến có dây đến không dây:

  1. Hầu hết các mạng đa hướng LAN, chẳng hạn như mDNS, được thực hiện bằng cách sử dụng các dải địa chỉ multicast đặc biệt không có nghĩa là được định tuyến qua các bộ định tuyến. Do các cổng nhà có khả năng Wi-Fi với NAT được kích hoạt là bộ định tuyến, mDNS không có nghĩa là chuyển từ mạng LAN sang [W] LAN. Nhưng nó NÊN làm việc từ LAN đến WLAN.
  2. Bởi vì các tín hiệu đa tuyến trên Wi-Fi phải được gửi ở tốc độ dữ liệu thấp, chúng chiếm rất nhiều thời gian phát sóng. Vì vậy, chúng "đắt đỏ" và bạn không muốn có quá nhiều trong số chúng. Điều đó trái ngược với cách mọi thứ hoạt động trên Ethernet có dây, trong đó các đa tuyến "ít tốn kém" hơn so với việc gửi các đơn vị riêng lẻ cho mỗi máy "điều chỉnh vào luồng video phát đa hướng" chẳng hạn. Do đó, nhiều AP Wi-Fi sẽ thực hiện "IGMP Snooping" để xem máy nào đang gửi yêu cầu Giao thức quản lý nhóm Internet (IGMP), bày tỏ mong muốn điều chỉnh luồng phát đa hướng nhất định. Các AP Wi-Fi thực hiện IGMP Snooping sẽ không tự động chuyển tiếp một số loại đa tuyến lên mạng không dây trừ khi họ thấy một máy khách không dây cố gắng đăng ký luồng đó qua IGMP. Các tài liệu mô tả cách thực hiện IGMP Snooping đúng cách cho thấy rõ rằng một số loại đa tuyến băng thông thấp (mDNS phù hợp trong danh mục này) được cho là luôn được chuyển tiếp ngay cả khi không ai yêu cầu rõ ràng về chúng thông qua IGMP. Tuy nhiên, tôi sẽ không ngạc nhiên nếu có các triển khai IGMP Snooping bị hỏng ngoài đó mà hoàn toàn không bao giờ chuyển tiếp bất kỳ loại phát đa hướng nào cho đến khi thấy yêu cầu IGMP cho nó.

tl; dr: Lỗi. Rất nhiều cơ hội cho lỗi. Và đôi khi các tính năng được thiết kế kém và lỗi cấu hình. Cách phòng ngừa tốt nhất của bạn là mua các AP chất lượng cao từ các công ty quan tâm đến việc đảm bảo đa tuyến hoạt động. Do Apple yêu thích Bonjour (mDNS) rất nhiều, nên các AP của Apple có lẽ là người xuất sắc nhất trong việc truyền đa tuyến một cách đáng tin cậy và các thiết bị khách Wi-Fi của Apple có lẽ là tuyệt vời nhất trong việc nhận tín hiệu đa hướng.


Tuyệt vời, cảm ơn bạn. @Spiff Có manh mối nào về mức độ không tương thích rộng rãi không?
hooby3dfx

@ hooby3dfx Đây chắc chắn không phải là vấn đề hiếm gặp, bởi vì tôi thấy câu hỏi về nó ở đây trên SU mọi lúc. Nhưng tôi không biết bao nhiêu phần trăm mạng Wi-Fi nhìn thấy vấn đề này.
Spiff

Bất cứ ai có thể biết? Bạn có biết các phương pháp thay thế cho các thiết bị trên WiFi để phát hiện ra các thiết bị có dây khác không?
hooby3dfx

1

@Spiff đã đưa ra một số điểm tuyệt vời trong câu trả lời của anh ấy và tôi sẽ không nhắc lại ở đây. Nhưng có một số câu trả lời và giải pháp thay thế khác để giải quyết vấn đề này.

Câu trả lời ngắn? Tôi không nghĩ rằng họ luôn "chặn" nhiều như vậy vì họ chỉ "không làm điều đó bắt đầu bằng" do sự lười biếng của kỹ sư tạo ra bất kỳ thiết bị cụ thể nào. Một số không có ưu tiên cao và một số không có thời gian để làm cho nó hoạt động.

Nó không cao trong danh sách ưu tiên so với tất cả các "tính năng" tiếp thị mới đang sử dụng để bán các thiết bị cấp tiêu dùng này và đó là một tính năng mà hầu hết những người không am hiểu về công nghệ không có manh mối, vì vậy hãy liệt kê danh sách ưu tiên cho đến khi trừ khi một nhóm lớn chủ sở hữu phàn nàn về nó, nó sẽ bị loại bỏ khỏi mọi cập nhật sửa đổi.

Nếu bạn muốn một thiết bị hỗ trợ nó, hãy chăm chỉ nghiên cứu và bạn sẽ nhận được một thiết bị hỗ trợ hoặc nếu bạn có thể tìm thấy một thiết bị mới hoặc đã qua sử dụng hỗ trợ một cái gì đó như OpenWrt hoặc Tomato từ Polarcloud, bạn có thể yên tâm nhận được những gì bạn cần.

Chúc may mắn. :)


1
+1 để sử dụng giải pháp được tiêu chuẩn hóa ít nhiều như OpenWRT, nơi bạn không gặp phải lỗi như vậy và nơi bạn có thể báo cáo các lỗi bạn tìm thấy và hy vọng sẽ sửa chúng.
Pavel imerda
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.