作者nfstako (sLc0mk tpR1ZE)
看板PC_Shopping
標題Re: [閒聊] 新一代Wi-Fi系統: 網狀網路 (Mesh Wi-Fi)
時間Sun Jan 21 21:31:35 2018
整體來說你對於Mesh的市場現況我沒有什麼意見。
不過在一些技術細節，我和你有不一樣的看法。
※ 引述《parislove3 (艾草糖)》之銘言：
: 一般在平面大範圍、多層透天厝布置 Wi-Fi 時，通常是單一大功率 AP、每層拉一個 AP
: 或是利用延伸器中繼擴大訊號，這些方式有時不盡人意
: 如訊號涵蓋不均造成死角，就必須調整 AP 擺設 & 天線角度
: 此外裝置無法從 A點 AP 自動切換至 B點 AP，移動後持續會咬住前一個 AP 訊號
: 必須手動斷線重連
其實訊號差的時候 WiFi Driver應該都要主動尋找下一個SSID嘗試連線
會持續咬住上一個訊號差的AP原因很多
可能是他找不到更好的，
可能是他覺得訊號還是不錯的，
(很多人會想辦法把AP刷機功率開很強，改天線，但是手機另一端根本打回去超弱
所以會造成手機根本不知道，只覺得AP的訊號超強，
造成手機沒有意識到，他的連線品質很差，該漫遊了。)
或者是他的漫遊機制根本就壞了。
: 這牽涉到消費級無線路由器的功能限制，一般不支援兩個技術
: ● Wireless AP Roaming
: ● 負載平衡
: 在商用、企業級的機器，802.11r Fast Transition Roaming 是基本功能
: AP 控制器與 AP 均開啟功能時，當偵測到裝置訊號不良後會自動剔除連線
: 使其連接至訊號良好的 AP
802.11r 說穿了就是讓Station(連線端以下簡稱STA)在切換基地台的時候，
省下EAPOL 4-way handshake的時間，
讓整個漫遊斷線的時間可以從幾百個ms，降低到幾十個ms。
802.11r主要有兩種，分成 Over-Air 和 Over-DS
以下我用Over-Air作為說明
https://alln-extcloud-storage.cisco.com/ciscoblogs/802.11r-image-2-550x356.png
我認為 「802.11r不會主動剔除訊號不良的STA」
從圖片可以看到，整個802.11r FT的過程，STA才是主導的一端。
其他的漫遊機制大部分也都是由STA主動發起。
從理論上，AP把STA剔掉是非常EZ的事情，只要對STA發出Deauth就可以了，
但是實務上，不會有原廠建議你為了漫遊這麼做。
原因如下：
1.
AP覺得STA的RSSI(訊號)不好，把STA踢掉後，
原AP沒有辦法確保STA有其他訊號更好的AP可以連線，
STA可能又跑回來跟原AP連線整個瞎忙一場。
2.
突然切斷STA，整個連線要重來，會耗費非常多重新建立連線時間
(為什麼要花很多時間註1解釋，有興趣自己看)，
如果STA正在打傳說會戰，一定會被送回家。
如果正在跟老婆語音or視訊 一定會被...?
所以AP主動發出Deauth對AP來說很簡單，但是對STA來說是殺他個措手不及。
那回到802.11r，STA他會覺得自己跟AP的訊號不好時，STA會預先在背景
用很短的時間，快速切換頻道送Probe，偷偷地先把附近可以用的AP資訊收集好，
決定好下一個AP是誰，才會主動啟動802.11r的機制。
你給的圖解居易科技，他們家有做出類似的功能，
https://goo.gl/vaqXHL
他可以減少第一個原因的情況發生，具體的實作細節我不太清楚
我猜應該是他們家的AP會紀錄Probe request的強度，並且在系統內的AP分享這個表，
確保，強制STA漫遊之後，他一定可以找到下一台訊號更好的AP。
但是這個強制漫遊，和802.11r一點關係也沒有。
===========================================================
註1: 重新連線光是L2要做很多事，Probe、Auth、Association、4 way-handshack。
Probe request、Probe response(要去找附近的基地台)
你斷線之後，
對STA第一個問題就是，要找一個訊號最好的AP連線。
第二個問題來了，WiFi的頻道這麼多，STA怎麼知道最適合的他AP在哪個頻道？
以台灣的iPhone來說2.4G有1-11ch可以用，5G有36-48、52-144、149-165，
對於STA來說，這件事超靠杯的你懂嗎？
搜尋頻道這件事情，不能同步做，因為理論上WiFi一次只能在一個頻道工作。
STA要在各個不同的頻道丟Probe request，然後不是射後不理，送完之後
還要等待附近的AP回覆，然後把他收到的可用AP記錄下來整理成一張表，
最後，再根據這張表，決定要嘗試跟哪個AP連線，整個Probe才算完成。
終局，你嘗試連線的AP可能壞了。
(你應該有手機自己公共WiFi然後，網路不通，怒把WiFi關一波的經驗)
挖哩勒～搞了一大圈，STA可能又跑回去連原本那顆AP。
(以下吃光光)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.217.163.63
※ 文章網址: https://webptt.com/m.aspx?n=bbs/PC_Shopping/M.1516541500.A.8A1.html
※ 編輯: nfstako (180.217.163.63), 01/21/2018 21:36:19
※ 編輯: nfstako (180.217.163.63), 01/21/2018 21:37:35
1F：推 b325019 : 我比較熟aruba的產品，aruba有個功能叫做client mat 01/21 22:00
2F：→ b325019 : ch，他會由controller去計算與他連線的設備跟各個ap 01/21 22:00
3F：→ b325019 : 之間的snr來決定要不要把user踢到別台ap上，不過這 01/21 22:00
4F：→ b325019 : 功能也跟11r無關就是了，而且目前有實作11r的幾乎都 01/21 22:00
5F：→ b325019 : 是ios設備安卓幾乎沒有，不過aruba的設定在企業型無 01/21 22:00
舊資料分享，HTC U11至今還不支援11r
https://goo.gl/i7wTMZ
6F：→ b325019 : 線網路來說也是數一數二複雜的很多si在這塊都沒有做 01/21 22:00
7F：→ b325019 : 適當的調整而導致這功能不能好好發揮 01/21 22:00
沒錯！
雖然AP主動斷線的功能，對STA好像很壞，
可是長期放任訊號差的STA做低速的封包傳輸，會拖慢同頻道所有人的速度。
所以以企業的營運角度來說，可能寧願犧牲訊號差的STA，保持整體的服務品質。
SI要了解這件事情，還要知道怎麼優化這些門檻值，這要做實地驗證和調教，
非常不容易。
8F：推 Jay915 : 感謝提供個人見解 01/21 22:09
※ 編輯: nfstako (180.217.163.63), 01/21/2018 22:43:57
9F：推 wahaha99 : 我覺得重點在於connect能持續?像是ptt這種 01/21 22:46
10F：→ wahaha99 : 一般來說你換AP一定會斷線 01/21 22:46
11F：推 Shauter : PTT是另外一回事 你要有登入IP做持續連線啊 01/21 22:53
12F：推 b325019 : 沒喔只要設定得當連ping都不會掉更不用說ptt 01/21 23:05
如果你的兩台AP是在L3同一個網路下，
(你可以把它想成在同一個IP分享器下面的兩台無線AP)
即使在L2 WiFi漫遊過去之後，L3在同一個網路下，
TCP還沒有超過斷線的最大限制，
那連線是有機會可以接回來的。
如果剛剛說的這個因為WiFi漫遊斷線的時間太久，
PTT Server或者是你的手機任何一方切斷TCP session 那PTT的連線就要整個重連了。
※ 編輯: nfstako (180.217.163.63), 01/21/2018 23:31:33
※ 編輯: nfstako (180.217.163.63), 01/21/2018 23:35:29
13F：推 Cubelia : 專業 01/21 23:32
14F：推 Windcws9Z : 我反而覺得主要不是無線漫遊斷線時間太久 01/22 00:38
15F：→ Windcws9Z : 最主要是Session 01/22 00:43
16F：→ Windcws9Z : 沒辦法從這個AP轉移給下一個漫遊的AP 01/22 00:43
要看你是怎麼部署的，session是L3以上的設備在維護的，
如果你是兩台IP分享器，然後有各自的DHCP/NAT，再把SSID設成一樣，
這樣Session一定會斷，因為漫遊過去之後
IP不一樣、Network不一樣、default GW也不一樣
WLAN漫遊是L2的事情，如果你換過去之後他還在同一個網路就可以有機會不斷線。
17F：→ Windcws9Z : 所以目前市面上的做法大致上有兩種 01/22 00:46
18F：→ Windcws9Z : 一種是一個當主控端其他皆為受控端 01/22 00:46
19F：→ Windcws9Z : 另外一種就是Mesh 01/22 00:48
20F：→ Windcws9Z : 傳統AP的問題是每一個都是獨立個體 01/22 00:51
21F：→ Windcws9Z : 雖然彼此之間互相連線但是並不會互相溝通 01/22 00:51
22F：→ Windcws9Z : 當然也就不會互相分享資訊 01/22 00:51
23F：推 birdy590 : thin AP還是最強大 但軟體會變的很複雜 01/22 00:52
24F：推 b325019 : thin ap也是有設定很簡單的像unify那類的只是設定簡 01/22 00:57
25F：→ b325019 : 單出問題就很難處理 01/22 00:57
26F：推 Windcws9Z : 我在猜或許可以從改進DHCP部份下手？！ 01/22 01:05
27F：推 s950435 : 好文推 01/22 01:47
28F：推 birdy590 : 最好的解法一定是在layer1 越高一定越差 切換越有感 01/22 02:26
29F：→ birdy590 : 所以IP mobility搞了那麼多年也沒商轉 01/22 02:28
30F：推 kaoh08 : 請問裝置端需要特別支援嗎？ 01/22 03:26
看你要做到什麼漫遊，如果只是訊號差自己斷線去跟下一顆AP重新建立連線，
這個不需要特別支援什麼。
但如果是特別的漫遊協定(802.11r 802.11k 802.11v)，這種當然要手機有支援才有。
雖然是舊的表了，但是可以參考一下。
https://goo.gl/i7wTMZ
31F：推 b325019 : 一般來說無線裝置不用特別支援，不過實務上我遇過原 01/22 12:02
32F：→ b325019 : 本漫遊都正常的手機不明原因會固定黏在AP上不會移動 01/22 12:02
33F：→ b325019 : 而造成漫遊斷線的問題 01/22 12:02
※ 編輯: nfstako (125.227.2.182), 01/22/2018 12:45:10
34F：推 Windcws9Z : 我跟你說一樣會斷 01/22 13:26
35F：→ Windcws9Z : 這是我老家網路架構 01/22 13:30
37F：推 ctes940008 : 推 01/22 13:32
38F：推 b325019 : fat ap玩無線漫遊會斷線不是新聞 01/22 13:33
39F：→ b325019 : 真的要玩買個最便宜的thin ap可能都還比較好 01/22 13:34
40F：→ Windcws9Z : 全部都在同個網段 01/22 13:34
41F：→ Windcws9Z : 2台RT-N16都是AP Mode 01/22 13:34
42F：→ Windcws9Z : 基本上各AP之間無線漫遊切換不會有感覺 01/22 13:34
43F：→ Windcws9Z : 但是如果是像PTT這種需要持續連線的 01/22 13:37
44F：→ Windcws9Z : 無線漫遊之後就會無法正常操作 01/22 13:37
45F：→ Windcws9Z : 不過也不算完全斷線 01/22 13:39
46F：→ Windcws9Z : 因為重新連線後PTT會告訴你有其他連線存在 01/22 13:39
47F：推 b325019 : 這個就是thin ap跟fat ap的差別了，因為fat ap之間 01/22 13:43
48F：→ b325019 : 並不會有資訊同步所以切換ap後會有session中斷的問 01/22 13:43
49F：→ b325019 : 題，而thin ap一般是由controller來紀錄流量所以漫 01/22 13:43
50F：→ b325019 : 遊不會有這個問題 01/22 13:43
51F：推 Windcws9Z : 如果你不重新連線 01/22 13:44
52F：→ Windcws9Z : 只要漫遊回去原本的AP 01/22 13:44
53F：→ Windcws9Z : PTT就又能恢復正常操作 01/22 13:44
54F：→ Windcws9Z : 樓上說的沒錯 01/22 13:45
55F：→ Windcws9Z : 問題就是在於各AP之間的Session資訊沒有同步 01/22 13:48
我跟你不一樣的看法，我理解的session是由NAT負責維護的，
各個AP Mode 的AP就只是一台L2 的switch，只是它是走wireless。
理論上 TCP session的維護是在RT-N18U上面就做掉了，
你漫遊過去之後，會感應到漫遊的只有兩台AP與HP 8Port switch，
當你把AP設成AP mode他就是一台L2的設備，
AP只是忠實地把你的無線封包橋接到有線設備(HP 8Port)上
所以我認為AP mode 不會維護session，也就沒有AP同步session的問題
L2的設備我沒有聽過有在維護連線session的，可能是我孤陋寡聞
有的話可以貼出來看看
當然你遇到斷線的問題，應該是有真實發生，但原因可能還有待驗證。
應該是手機和N18U之間有什麼東西沒處理乾淨。
(先看看你漫遊過去之後，手機拿到的IP 有沒有變)
57F：→ deadwood : 所以才需要controller啊... 01/22 17:47
※ 編輯: nfstako (125.227.2.182), 01/22/2018 18:28:32
58F：推 roger225 : 推薦LEDE 802.11r ptt不會斷 開源 透天好物 01/22 20:59
59F：推 speaper : 看到這突然猶豫要不要分享玩了一個多月Deco M5的心 01/23 03:17
60F：→ speaper : 得了… 01/23 03:17
61F：推 Windcws9Z : Nope 手機IP不變 01/23 12:59
62F：→ Windcws9Z : 有空你自己做個實驗就知道惹 01/23 13:01
63F：→ Windcws9Z : 不然怎麼會需要Thin AP甚至是更平價的Mesh呢 01/23 13:08
Thin AP是給企業大量部署的時候才會好用，
部署一台Thin AP跟部署1台家用的AP你就會知道，
你可以試試看UniFi他們家的Thin AP
Mesh 是給佈線不方便又想要WiFi覆蓋率的使用者用的(比較適合大坪數或店家)
小弟不才在WiFi相關的網路公司開發韌體，做過很多實驗，沒有遇到類似的問題。
※ 編輯: nfstako (118.150.29.44), 01/23/2018 13:50:27
64F：推 lingling0000: 長知識感謝推 01/23 23:53
65F：推 andrew5106 : 太猛了，借問一下哦 01/24 07:42
66F：→ andrew5106 : 假設數據機設硬撥了，那不同樓層的WIFI皆設為同樣的 01/24 07:42
67F：→ andrew5106 : SSID 01/24 07:42
68F：→ andrew5106 : 那他切換的時候也會斷線嗎？ 01/24 07:42
69F：→ andrew5106 : 還是視為同一個網路環境呢？ 01/24 07:42
70F：→ andrew5106 : 謝謝解答 01/24 07:42
71F：→ Windcws9Z : 怎麼可能沒有類似的問題@@？！ 01/24 23:32
72F：→ Windcws9Z : 那Mesh是出假的喔 01/24 23:33
73F：→ Windcws9Z : 你自己拿幾台家用AP兜起來不就知道了？！ 01/24 23:35
74F：→ Windcws9Z : 如果你真的有這麼神 01/24 23:38
75F：→ Windcws9Z : 有辦法讓家用AP在無線漫遊的時候不會斷線 01/24 23:38
76F：→ Windcws9Z : 那麻煩請你移駕至Broad_band專版 01/24 23:42
77F：→ Windcws9Z : 教一下大家要怎麼設定家用AP無線漫遊吧 01/24 23:42
78F：推 soto2080 : Z樓上別凹啦 樓主是對的 換手做得好 roaming 沒煩 06/07 19:31
79F：→ soto2080 : 惱 06/07 19:31
80F：噓 Windcws9Z: 凹什麼，哪有啥好凹的？ 59.127.190.36 04/27 14:56
81F：推 Windcws9Z: 實測結果就是如此啊，我設備都還在 59.127.190.36 04/27 14:59
82F：→ Windcws9Z: 不信來測一一 59.127.190.36 04/27 14:59
83F：→ Windcws9Z: 架構只有RT-N16升級Mesh水星H50G 59.127.190.36 04/27 15:05
84F：→ Windcws9Z: 一樣都跑AP Mode，後者就能正常 59.127.190.36 04/27 15:06
85F：→ Windcws9Z: 無線漫遊 59.127.190.36 04/27 15:06