→ jeff40108: Aimesh=拉雞 08/09 13:14
→ jeff40108: 建議砍掉重練，買真mesh 08/09 13:14
→ tomap41017: 推一樓 08/09 16:25
→ jior: 真的，直接買真的mesh吧 08/09 21:36
推 Windcws9Z: AiMesh≠Mesh 08/09 22:51
→ asdfghjklasd: 直接用 ThinAP 08/09 23:18
→ birdy590: 現在趨勢 thin AP 越來愈少了吧 連商業產品都開始用 08/10 00:06
→ birdy590: 現成 wisoc 去湊 AC+AP, 但這樣出來還是 fat AP 08/10 00:07
→ birdy590: 沒辦法 不這樣搞開發速度太慢 根本沒競爭力 08/10 00:07
推 asdfghjklasd: 我們專弄不是一般用法的wifi，你說的那東西我們不用 08/10 21:12
→ asdfghjklasd: 到是現在除了ThinAP, FatAP外,,又往Cloud AP去了 08/10 21:13
→ asdfghjklasd: 這市場也起來了~~~ 08/10 21:13
→ HiJimmy: Cloud AP是像之前Fon Ap那樣? 08/10 22:02
→ asdfghjklasd: 其實就是控制器變雲端化了.使用者簡單容易管理設定 08/10 22:51
→ asdfghjklasd: cisco meraki , aruba instant on 08/10 22:52
→ asdfghjklasd: Ruckus Cloud Wi-Fi 等,我自己是用 instant on 08/10 23:02
推 lianpig5566: 沒記錯的話，最早搞控制器雲端化的應該是Unifi? 08/11 00:33
推 ptckimo: 商業版的ThiAP？不難找啊！DrayTek VigorAP 903組mesh超 08/12 16:19
→ ptckimo: 好用，pchome udn都有賣，預算夠的話用這個不後悔 08/12 16:20
→ uxtz: 想要mesh建議是直接上啦，這種用ai mesh去湊得真的不穩 08/12 23:56
→ uxtz: 如果有舊款建議就拿來當純路由器用吧.... 08/12 23:56
推 birdy590: 現在不流行 ThinAP 了... UBNT 有說明 頻道要統一是硬傷 08/13 00:09
→ birdy590: 雖然妥善規劃下漫遊效果是最好 但實在太貴又太麻煩 08/13 00:10
→ birdy590: 開發軟體去控制現成 wifi 晶片 效果接近但便宜很多 08/13 00:13
推 Windcws9Z: Thin AP是價格問題，商用一堆哪裡不流行 08/13 11:52
→ Windcws9Z: 穩定 功能根本屌打Mesh 08/13 11:52
→ Windcws9Z: Thin AP由控制器統一管理，我是不知道哪裡麻煩喇 08/13 11:55
推 birdy590: 不是講了嗎 頻道必須一樣 設計上困難會很大 08/13 12:42
→ birdy590: 所以會有各式各樣當天線 儘量把空間切開不要重疊 08/13 12:43
→ birdy590: 用fast roaming就簡單多了 頻道錯開就好 剩下讓裝置自 08/13 12:44
→ birdy590: 己選 08/13 12:44
→ asdfghjklasd: 誰跟你說頻道要一樣? 08/13 14:47
→ asdfghjklasd: cisco / aruba ThinAP在有 AC 下,自己2.4Ghz 08/13 14:56
→ asdfghjklasd: 鄰近AP 都會 1 6 11 分開不重複 08/13 14:56
→ asdfghjklasd: 一但 CH 統一了就是信號品質會不良.ch 使用率會高 08/13 14:57
→ asdfghjklasd: 有空自己開inSSIDer 看看有 ThinAP 的環境多顆 08/13 14:58
→ asdfghjklasd: ch 是怎分佈的 08/13 14:58
→ asdfghjklasd: UBNT 若會寫出這樣的話,我應該不會用他們家的東西 08/13 14:59
→ birdy590: 等一下 通通錯開 請問一下要如何漫遊? 08/13 15:00
→ birdy590: 用 k/v/r 做漫遊的 節點大概也瘦不到哪裡去吧 08/13 15:02
→ birdy590: 我是認為傳統定義的"thin AP"早就已經絕種了 08/13 15:06
→ asdfghjklasd: 照樣漫遊~~~沒有家用ap樣的問題 08/13 15:07
→ birdy590: 那個年代包括漫遊全都是由 AC 控制, 頻道錯開不用重連? 08/13 15:08
→ birdy590: 一個蘿蔔一個坑 怎麼可能照樣漫遊 @@ 08/13 15:08
→ birdy590: 這得先回到開頭 "thin AP"的定義到底是什麼 08/13 15:09
→ birdy590: 像 Cisco 就直接改叫 lightweight ap, 舊定義根本不用了 08/13 15:13
→ asdfghjklasd: ThinAP , FatAP 現在比較是一個名詞..... 08/13 16:59
推 Windcws9Z: ThinAP沒有頻道必須一樣，那是Mesh的問題 08/13 22:38
→ Windcws9Z: 正常鄰近AP頻道都要錯開，不然會自己打自己 08/13 22:41
→ birdy590: 這樣就是沒漫遊啊 QQ 莫忘 thin AP 比那些漫遊協定還老 08/14 00:24
→ birdy590: 以前 UBNT 還做了 Zero-Handoff Roaming, 現在也退休了 08/14 00:24
→ birdy590: 還是定義的問題 如果 thin AP 定義退化到"由中央控制器 08/14 00:25
→ birdy590: 統一設定" 我認為這其實已經脫離原本的意思了 08/14 00:25
→ birdy590: 我記得最原始的定義應該是 AP 只負責 radio, 其它全部 08/14 00:26
→ birdy590: 由控制器來做 當然這不會有什麼"個別設定"的問題 08/14 00:26
→ birdy590: 所以 像Cisco這樣直接改用自己的定義可能更好些 08/14 00:27
推 Windcws9Z: ？？？？ 08/14 11:22
→ Windcws9Z: 最早能夠漫遊的就是ThinAP，你還在那邊沒有漫遊 08/14 11:24
→ birdy590: 你沒看上面討論 那就是得用同樣頻道 不然要怎麼漫遊? 08/14 11:27
→ birdy590: wifi 不重新連線有辦法換頻道? 08/14 11:28
→ Windcws9Z: 然後ThinAP本來就要有Controller，哪來的定義退化 08/14 11:28
→ birdy590: 看清楚點 我的是"只剩下由中央控制器統一設定" 08/14 11:28
→ birdy590: 但後來的 AC+AP, cloud AP 也都是這樣 但一點也不 thin 08/14 11:28
→ birdy590: 最早的 thinAP 節點應該只負責 radio, 就像是台超大 AP 08/14 11:29
→ Windcws9Z: ThinAP一直都是由Controller統一設定管理好爆一一 08/14 11:29
→ birdy590: 對 但這部份不是重點啊 中央控制就會 thin 嗎? 08/14 11:29
→ birdy590: 本來最重要的特性 在環境變化之後條件已經不存在了 08/14 11:30
→ Windcws9Z: 我D老天鵝R 08/14 11:30
→ birdy590: 所以上面一開始不是就問了 "得先弄清楚 thin AP 的定義" 08/14 11:31
→ birdy590: 原始定義從來就不是"由中央控制器統一管理 那只是個角" 08/14 11:31
→ birdy590: 或者說是 節點功能極度簡化後的必然結果 08/14 11:31
→ birdy590: 節點只靠本身根本不能獨立工作 如何不由中央統一管理 08/14 11:32
推 Windcws9Z: ThinAP FatAP定義一直都是這樣，是你搞不清楚八一一 08/14 11:37
→ birdy590: 一直都是"哪樣"? 08/14 11:38
→ birdy590: "Thin AP只提供無線訊號傳遞" 2005年的大標題是長這樣 08/14 11:39
→ birdy590: 這個時候當然是沒有漫遊的 所以才會講 ubnt 的 zhr 08/14 11:39
推 Windcws9Z: 我D老天鵝R 08/14 11:41
→ Windcws9Z: 難怪asdf版友會懶得講話 08/14 11:43
推 birdy590: 他應該是看懂漫遊的問題了 不然你的 thin/FAT 毫無分別 08/14 11:47
→ birdy590: 你自己都沒發現這種定義已經失去意義了? 08/14 11:47
→ birdy590: 請問一下 把一堆 fat AP 安裝中控系統 會不會變瘦 08/14 11:47
→ birdy590: 照這種邏輯連 aimesh 都變成 thin AP 了, 到底哪裡瘦了 08/14 11:48
推 Windcws9Z: 因為人家該講的都講完惹，結果你還是卡在那邊 08/14 11:55
→ birdy590: 不要迴避問題嘛, 請問一下 aimesh 是不是 thin AP 08/14 11:56
→ birdy590: 一個定義如果本身就無法自圓其說 就肯定有問題 08/14 11:57
→ birdy590: 我連解釋都給你了還看不懂? 原始定義的 thin AP 已滅絕 08/14 11:58
→ birdy590: 像上面思科這種作法 直接自己創造一套新的定義才是正途 08/14 11:59
→ Windcws9Z: 從頭到尾就你搞不清楚定義，哪來不能自圓其說 08/14 11:59
→ birdy590: 麻煩請你用你的定義解釋一下 aimesh 為什麼不是 thin AP 08/14 12:00
→ birdy590: 因為這個"控制器"的工作範圍 你根本連碰都沒碰 08/14 12:01
→ Windcws9Z: 先不說華碩的AiMesh≠Mesh 08/14 12:02
→ Windcws9Z: AiMesh關掉能不能單獨運作？可以啊 08/14 12:02
→ Windcws9Z: 那就是FatAP啊，這很難懂嗎 08/14 12:02
→ birdy590: 這到底什麼爛定義 @@ 08/14 12:03
→ Windcws9Z: ThinAP沒Controller就不能動，這真的很難懂嗎？？？？ 08/14 12:03
→ birdy590: 我就明白講啦 現在很多控制器做的事情跟以前根本不一樣 08/14 12:03
→ birdy590: 不然哪可能會出現 cloud AP? 那就真的只負責管理而已 08/14 12:04
→ birdy590: 還有一些微型的控制器 只做最少的工作 08/14 12:04
→ birdy590: 如果不知道底下發生什麼事情 麻煩不要隨便亂下定義 08/14 12:05
→ birdy590: 有沒有想過為什麼可以在裝置完全不動 也沒有漫遊協定 08/14 12:05
→ birdy590: 的條件下照樣做出漫遊? 而且效果其實是比 k/v/r 還好 08/14 12:05
推 Windcws9Z: 我還真不知道這摸簡單的定義會有人不懂 08/14 12:06
→ Windcws9Z: 啊對定義也不是我下的，感恩 08/14 12:06
→ birdy590: (然後順便補充一下, 就連AiMesh≠Mesh可能也有必要修正 08/14 12:07
→ birdy590: 不知道有多少人發現, 多數平台上 k/v 都已經開了 08/14 12:08
→ birdy590: thin AP 的原始定義上面有 "節點只提供無限訊號傳遞" 08/14 12:08
→ birdy590: 一開始控制器的工作是很多的 根本不可能搞什麼雲端 08/14 12:09
→ birdy590: 設定節點只是它工作的一塊, 不是設定完就沒事了 08/14 12:09
→ birdy590: 那時候的節點性質比較像延伸出去的天線 所以很多可以玩 08/14 12:10
→ birdy590: 中控要把裝置搬到另一個節點 裝置甚至根本不知道 08/14 12:10
→ birdy590: 不然你告訴我沒有漫遊協定還能怎麼漫遊? 08/14 12:10
→ birdy590: 但是用現在的硬體這個做不到 因為很多工作都下放了 08/14 12:11
→ birdy590: 不再只是提供無線訊號傳遞 自然就談不上"thin" 08/14 12:12
→ birdy590: 硬體上跟一般AP沒什麼分別 韌體做的事情搞不好還更複雜 08/14 12:14
→ asdfghjklasd: 我是懶得說了... 08/15 22:45
→ asdfghjklasd: 我工作規劃的環境都是給數百人上顆顆AP的運作 08/15 22:46
→ asdfghjklasd: 懂無線通訊的人就不會說漫遊一定是要同一個頻道了 08/15 22:46
→ asdfghjklasd: ThinAP就是自己本身不負責RF/auth的部份, 08/15 22:47
→ asdfghjklasd: 就是自己開起來後..所有的動作用控制器來指揮 08/15 22:47
→ asdfghjklasd: 聰明的控制器會自己感知AP附新的頻道使用情況 08/15 22:48
→ asdfghjklasd: 自動使用較少使用率的頻道. 08/15 22:49
→ asdfghjklasd: ThinAP 架構下有沒有可能用 11kvr ? 有可能也有的 08/15 22:50
→ asdfghjklasd: 人家可以做的事比 FAP 多太多了, 08/15 22:51
→ asdfghjklasd: 802.1x , mac auth , portal auth 等 08/15 22:51
→ asdfghjklasd: 真的不明白可以去看看 cisco 白皮書 08/15 22:52
→ asdfghjklasd: 真想了解 可以去 查一下 CAPWAP 08/15 23:02
→ asdfghjklasd: 想要自己搞自己的 AC + AP 可以看 open CAPWAP 08/15 23:03
→ birdy590: 你沒講反過來那面啊, thin AP 當然可以用 kvr 08/15 23:33
→ birdy590: 但是不靠 kvr 能不能做出無縫漫遊? 當時那可是賣點之一 08/15 23:34
→ birdy590: 現實是有 kvr 之後 廠商發現根本沒必要像以前那麼辛苦 08/15 23:34
→ birdy590: 你應該也很瞭解 對裝置來說 換頻道其實就等於重連 08/15 23:35
→ birdy590: 重連就不會是無縫... 當時 ZHR 的漫遊效果比 k/v/r 還強 08/15 23:35
→ birdy590: 開頭 thin AP 頻道當然可以錯開, 但要做漫遊就不行了 08/15 23:45
→ birdy590: 有了 k/v/r, 變成裝置也參一咖以後 沒必要再做那麼 thin 08/15 23:46
→ birdy590: 所以幾乎絕種了... 大致上完整的 story 應該長這樣 08/15 23:47
→ asdfghjklasd: 隨便你啦. 看不懂就算了 08/16 00:05
→ birdy590: 沒有看不懂啊 前因後果都講了 08/16 00:16
→ birdy590: 不然大師開示一下 沒有漫遊協定的時候要怎麼漫遊 08/16 00:16
→ birdy590: 主要是在講裝置的行為 有些觀念就算家用單AP也適用 08/16 00:49