本週末即是一年一度的開源人年會,記得去年陸續辦過 OSDC, Blog BoF, COSCUP2008 文化與科技國際博覽會 (Culture Mondo Network) 等。有時成功、偶爾失敗,但是大多失敗的問題都是頻寬不足,像是 Blog BoF 第一次只用 8M/640K Hinet ADSL 寬頻,碰到大流量的 Y!Live 視訊就被衝爆了,雖然 Y!Live 已經收掉了,但是現在 High-definition video 的視訊串流網站也已經變得相當普及,萬一演講太無趣,大家都上線看 Youtube *誤* 那也很有機會爆掉。

記得 2008 文化與科技國際博覽會,在展場與主會議廳各拉一條中華 10M 光纖,使用上倒是沒有甚麽大問題,倒是因為 WiFi 的流量限制較嚴格,某些聽眾想即時上傳視訊影片到外部網站,造成了一些問題。剩下的一般網路瀏覽、Skype、讓 im.tv 做即時視訊轉播,又再現場同時開兩台播出都沒有大問題。(當然也可能是因為這個博覽會的聽眾比較不需要即時網路)

今年四月的時候,又當了一次 OSDC 的義工。今年 OSDC 的是使用台灣微軟的會議室七樓會議室 (對,參加開放原始碼軟體研討會,卻在小便斗上看到微軟的催眠文宣貼紙,的確有點奇特的趣味),這次雖提早去了一次場勘,但是礙於政策或麻煩等種種問題,微軟只能提供分別於內部網路外的一條 2M/256K 的中華電信 ADSL 線路,對於我們所提供會有大量的使用者上網的需求,相關人員露出了納悶與不解的神情,直說其實大部分微軟的聽眾都自備 3G 搞定啊,為何需要額外架設無線網路。且若要使用現成無線網路,尚需要額外申請大量帳號。於是,就在半脫半就的狀況下用了 2M/256K 的線路提供大約兩百餘聽眾的會場網路。

下場當然不會太好看。頭一天是 Tutorial, 因為人數不多,因此網路頻寬的流量使用率還好。但是驚爆一個問題,原來接進會議室的上游是一台 D-Link 的 DI-704P 寬頻路由器 (直接接到神秘的內部網路孔去,只好透過 nmap/telnet/mac address 辨識),這台機器只要超過 1K connection sessions 就自爆,剩下的連線都死光,很有可能是因為還接了其他網路或設備,造成可容納數下降,無法察知。

於是當日結束後,請微軟的網管協助,希望直接將 DI-704P 的 WAN 網路線直接插到該孔,如此我們就可以用自己的設備自行撥 ADSL 的 PPPoE 出去。很妙的是,沒有人知道這台神秘的 D-Link DI-704P 接到哪裡去,找不到機器、也找不到線。於是第一天下午結束後,在 gslin, XDite, slzzp 及其他大神的建議下,趕快生了一台有雙網路卡的小電腦出來,裝上 Debian、OpenVPN、shorewall,從微軟的中華電信 ADSL 開 tunnel 到台灣大學,繞過該死的 D-Link DI-704P。這也是為甚麽大家從微軟上網,出去的 IP 卻是台灣大學。這樣算是解決了 DI-704P 自爆的問題。感謝 gslin, XDite, slzzp 及其他朋友當日空著肚子陪我測試最後效果。

不過 2M 的水管根本不夠大家用阿,上線的人數大約是 40-60 人,完完全全不夠分。於是只好開始

  • (在微軟會議室)擋掉頻寬吃最兇的 Windows Updates Services
  • 擋掉 Debian/Ubuntu mirror site. (造成一些人在外面想測試、安裝新軟體,卻完全連不上)
  • 最後一天下午,已經沒法子了。只好把 transparent proxy 設起來,除了講者之外,其他人輪流斷 Web Access,會看到小水管不夠用的畫面)

很苦。另外也碰到一個問題,就是現場其實有一台 SMC SMCWBR14S-N2,是微軟拿來開放給聽眾使用,因為我已帶了自己的設備,於是打算將他拿來給講者專用。由於原始的設定都是出廠預設值,於是改了密碼、訊號名稱,以及加密方式從 WPA 改為 WEP (為了擔心有講者拿了太舊得電腦連不上),但是在第三天早上劉燈與 David Heinemeier Hansson 做 Video conference 時,將所有的自有 AP 都拔掉,剩下 SMC 這台。但是網路卻很巧妙的每次等劉燈問完一個問題、回答到一半的時候,就斷線了,連續試了幾次,每次都要再補充說明一次,大家都有點失去耐心了。這個問題因演講進行中一直沒有機會辨識跟解決,無法察知是 SMC 的問題、抑或又是 D-Link DI-704P 的異常。(SMCWBR14S-N2 乃直接接到 DI-704P 上)

一些下次可以注意的細節

  • 應該要監視流量與使用頻率,這牽涉到網路佈署的 topology 。不過若能收集這些資訊,對未來改善研討會的網路環境會很有幫助。
  • 要有心跳 (heartbeat) 監視系統,更好是超過時間未收到心跳,則發簡訊通知。
  • 若使用現場網路設備,更改掉預設設定還是必要得。預設密碼、UPnP 等都要更改、關掉為佳。開源研討會,特別有高手會動手動腳、玩刀弄槍的 😉 。當然、無必要的話,就不要用沒測過的設備來玩。
  • 講者若需要使用視訊、網路電話,無論如何再怎麼機車都要麻煩講者與大會提早測試一遍。

今年 2009 開源人年會將再次租用台灣大學應力所與台大電機博理館,今年籌備團隊特別注意台大的網路是否又會拿週末的時間來進行維護,除了上網看電算中心公告,也請教了內線消息,所幸到目前為止都還沒有這樣的網路、電力的維護安排。今年 COSCUP 人數光聽眾就高達 550 人,希望今年乖乖大神保佑,不要出事阿。

(這篇文章因為事隔數月,可能人名或事項過程有所差異,若有誤記請指教並請見諒)

D-Link DI-707P

根據 xdite 的心得感想,要辦好網路社群為主的會議,有三個主要重點

「正妹工作人員要多,即使少也不能傷眼,最好是有拍回去讓人炫耀的水準」
「網路品質要好,即使很慢也要不能一直狂斷,有線網路是最佳選擇」
「點心要好吃,不好吃也要讓人人吃到飽,最好是茶點時間超級長」

網路一直都是網路社群研討會籌辦者的痛苦,這些參與者本來就是隨時掛網的傢伙,要是參加了激發想像力的會議,卻沒有辦法馬上把資料上傳到網路上或跟網友討論,立即就會見到整個會場充滿焦慮惱怒的氣氛,這時就不用期待會議會有甚麼迴響了。

偏偏大部分的會議場所,基礎環境都不夠完備,缺電缺網路是正常不過的事情。網路的佈建若是要拉線到每個座位上,光是佈線的費用就大約比場租還貴,更何況還得籌備 Switch/Routers 等網路設備。

所以通常是以無線網路作為基礎,然而臨時要借來一堆無線網路基地台也不是一件容易的事情阿,因此都得到處請託。借到設備後也得顧慮佈建的方式,除了基本的 Site Survey 了解場地的大小與障礙物外,以便判斷該將 Access Point 部屬在什麼地方,以及選用適當的天線。最好還要準備 Spectrum Analyzer 等工具,以便決定如何分派有限的通訊頻道。若缺乏了這些工具,想臨時辦好無線網路這件事情並沒有那麼容易阿。

先前幾次經驗,若是透過場地現有的無線網路,要嘛就是被基地台擋了大部分服務 (ports),只允許網頁(Port 80, 443)等流量,否則就是需要帳號密碼,於是乎大家搶著用有限的帳號上線,手腳慢的傢伙只好眼睜睜看著鄰居上網,自己卻只能乖乖離線聽演講。至於自備基地台這件事情,也時常發生取用了家用型基地台 (因為預算的問題),結果沒多久就爆炸 (因為記憶體不足或太多 connection sessions).

FON 先前贊助提供幾個研討會像是 HIT, Wikimania, 中國網誌年會 基地台,據說也是瞬間就被打爆了,形象大傷。可能是佈建的方式 (無法判別該如何使用不同的頻道) 或 Fonera 本身設計的瑕疵 (先前有軔體穩定度與強迫使用歐洲的名稱伺服器的問題)。

這次答應 OSDC.TW 作網路志工,決定採取不同的策略,就是把借來的一打 Fonera 全部重燒成 OpenWrt 為基礎的客製化軔體,並做了以下設定

  • 做了 Management console, 包含設定多一個 IP Address,可以用有線網路接入基地台作設定。並放了 X-Wrt,以便萬一出了問題,可以臨時以網頁改設定為 WDS/Mesh Network. 當然也得放 dropbear (ssh) 作為後備措施。事實是,本次幾乎都是用 ssh 作遠端監視、管理維護。
  • 將 net.ipv4.tcp_fin_timeout, net.ipv4.tcp_keepalive_time, net.ipv4.netfilter.ip_conntrack_tcp_timeout_established 等 kernel parameters 都設到極小,以降低系統紀錄 TCP Sessions 時間。並調高 net.ipv4.netfilter.ip_conntrack_max 數倍以上,如此可以容納更多人同時上網存取。
  • 做了 QoS,將 ssh/web 優先值調高,而且調高 ACK/SYN ,降低其他所有 Port 的優先值。所以理論上 IRC/Internet surfing 不會 lag,即使流量極高, ssh / telnet 也會有比較快的連線反應。(只要 802.11 layer protocol 沒有問題,頻譜沒有被干擾)

本次 OSDC 會議其實只用到五台 Access Points (FON Fonera),參加人數大約 240-250 人,出席人數大約都是一百餘人,同時無線上網人數大約是 60-80 人,會議期間連線沒有甚麼大問題,只有以下兩個問題

  1. OpenWrt trunk 的 atheros hal binary 有相容性問題,所以 Intel® PRO/Wireless 2100 網路卡 無法連線,既使更新了驅動程式與關閉 PSP。受害的苦主有 mhsin、pofeng 等人。不過該 hal 是 property software,沒有跟 Atheros 簽署 NDA 拿不到程式碼,因此也無從修起。即使社群做的 OpenHal/ath5k 也尚未到達堪用的程度。因此還需努力想辦法解決才行。
  2. 場地電源負載過高,跳電造成基地台停止運作。 *默* 這完全在預期之外,不過連線都轉移到剩下還有電源的基地台上。線上查了一下紀錄,每台 AP 上 associated 了大約 40 餘台 STA,但系統 loading average 尚未超過 1, 且尚有記憶體。除了角落的朋友收訊變糟外,並未造成太大的影響。

以上,是本次無線網路服務檢討報告。:-)