Tag: openwrt

Posted on
by

簡單講，就是這次活動網路遜掉了。

主要問題是場地對外頻寬不足，只拉了一條 8M/640K Hinet ADSL，於是變成大家都可以連上無線網路系統，可是卻無法快速的下載網站，或順暢的使用 Y!Live 與 Skype.

先說明場地的佈建方式，原先第一次場勘的時候，外面的贊助商帳篷預計是要搭設於 B 廳與 C 廳間的廣場(場地平面圖)。由於廣場與 A 廳中間還有其他建築物，當日也還有展覽，為了避免佈線的麻煩，建議籌辦單位準備兩條 8M/640K，分別拉線於兩棟建築物。

結果後來出席活動前一週的籌備會議時，才知道要將各贊助商攤位移至緊臨 A 廳的廣場，對外網路也暫時只改申請一條 8M/640K。會議上，籌辦人不停的詢問我，8M/640K 是否夠用？只要我說一句「不夠用」，他會馬上再去申請一條沒問題。不過當下活動支出已經稍微超出預算，若換了網路，恐怕得少買一些食物。

甚麼！居然要拿網路會議三寶 (網路會議有三寶，正妹、網路、食物不能少) 來互換，身為阿宅的我當下決定拿出男子漢的氣概，咬著牙說「行！」。畢竟一條中華電信得 8M/640K 臨時短期租用可以換很多很多食物阿。(這個決定是災難的開始)

現場使用的設備跟上次 OSDC 差不多，一樣是從 FON 臨時借用了一些產品跟網路設備。並且將軔體全部換為客制化過的 OpenWrt。不同的是，由於上次 OSDC 使用的會議室已經有學術網路跟網路佈線，因此完全不用顧慮現場拉線跟頻寬的問題。

這次 Blog BoF 是臨時佈建，現場沒有任何現存的線路與管道。且場地分為兩個部份，在內場 A 廳的部份，佔地約 10Mx50M，屬於長狹空曠型。但是由於場地內人員會走來走去，若只靠一台機器或前後各一台，勢必會因為人員走動而干擾無線網路訊號。而外面廣場與 A 廳則隔了一個小山坡，無線勢必受到干擾。於是使了一些方法讓全場都可以覆蓋到無線網路訊號。

最後的作法是於圖中藍色甲一工作人員區設定為總部，中華電信 8M/640K ADSL 接於此。中華電信小烏龜給了一台康全電訊 CT-511C，只有單孔網路，於是接出至 SMC FMCFS5，示意圖如下

其中甲一、乙與丙一，各接了一台寬頻路由器，與一台無線網路基地台。其中藍色甲一作為主要服務基地台，接於 Buffalo BBR-4HG，搭配 FON 指向性天線與甲二的 Repeater 大致可以覆蓋整個內場。使用人數一直都保持於 30-50 人，整天都正常運作。只有中途因為手殘改亂了設定，重新開機一次。

至於紫色乙區，則是提供給講者、Y!Live 廣播及前排觀眾使用。使用了 SMC SMCWBR14T-G 與一台無線網路基地台，SMC SMCWBR14T-G 已經關閉它的無線功能，讓另外一台 FON 無線網路基地台負責。沒想到它整日還是當機了三、四次，造成 OpenWrtF 與 Y!Live 中斷服務。SMC SMCWBR14T-G 是個很糟的產品。

而綠色丙一區則使用 D-Link DI-624S 與 FON 無線網路基地台。一樣關閉 DI-624S 的無線網路功能，靠 FON 運作，丙二則使用 Wireless Repeater 將訊號接取廣播到戶外舞台另外一側。不過下午因為曬太陽的緣故，丙一舞台旁的 FON 熱壞了，重開機一次，重新開機期間丙二則自動切換廣播甲一的無線訊號。

如此的規劃，大致上沒有嚴重的問題。由於會場都收的到訊號，且週邊 2.4Ghz 頻段很安靜，所以無線大致上沒有問題，只要持續監測他們正常運作即可。麻煩的是，由於這次拿到三個公開 IP，各接於不同的 Router，非常不方便監控每一台的流量與狀態。下次應該把他們都換成開放原碼的軔體才是。

這次最嚴重的問題就是頻寬完全不足！整天都非常專心的再監測到底頻寬被哪些人吃掉了，並且試著把他們暫時踢掉，把頻寬讓給其他人使用。當下發現場內許多人都不停的使用 Y!Live, Twitter 與 Butoo。

剛稍微測試了一下最吃頻寬的 Y!Live，收到以下的數據

狀態 下傳 (kBit/s) 上傳 (kBit/s) 8M/640K 大約承載使用者數
瀏覽視訊/不開視訊 700~800 10~15 10
瀏覽視訊/視訊討論 1100~1500 80~200 3
廣播視訊 300~400 300~400 2
瀏覽熱到爆頻道 3200~3500 60 2

若純粹瀏覽 Y!Live 單一頻道，且頻道其他聽眾沒有開啟視訊/語音的狀態平均需要下載 700~800 kBit/s, 上傳 10~15 kBit/s。若把自己的 WebCam 也開啟，進行單位觀眾對頻道主人視訊對話的話則需要下載 1100~1500 kBit/s, 上傳 80~200 kBit/s。而自己開設頻道所需的頻寬，且觀眾都未開語音時，需要 120~150 kBit/s，上傳 80~200 kBit/s。

上述都是單純的使用。根據昨天 Blog BoF 頻道的盛況，同時有四五頻道訪客加入視訊討論，由於會同時收到數人的影像，需要的頻寬至少需要下載 3200~3500 kBit/s, 上傳需要 60 kBit/s.

如此證明，只要超過十個人開啟 Y!Live 瀏覽視訊，會場的 8M 線路就會爆掉。超過兩人進入 Blog BoF 視訊頻道，現場網路就會滿載。

問題在於昨天上午活動開始時，每位有電腦的朋友都會開啟 Blog BoF 首頁去看議程，偏偏 Blog BoF 首頁就內嵌了 Y!Live 視窗，於是很不幸的，上午的狀況非常的糟。第一場過後就開始在場內每台機器上擋掉 Y!Live 網址，如此至少眾人不會不停的於場內同時開啟 Y!Live.

不過麻煩的是大家還是會不停的、連續的讀取 Twitter 或巴布的回應，剛剛測試了一下類似的行為會用掉平均下傳 65~150 kBit/s, 上載 15~30 kBit/s。8M 預計可以支撐 20 餘人，就算兩條 ADSL 也只能承受 40 人這樣搞阿。就算拉了多條線，也得再處理分流的問題才能有效分擔流量。

下午的時候，負責轉播的 Tyler Lin 已經暫時轉移到備援的 3G 網路上 (因此下午影音效果可能不佳)。問題是大家還同時開 Youtube/Y!Live/Skype/PTT/Twitter/Buboo 阿，其中光是 Skype 對話大約需要 200~300/100~150 kBit/s。會場平均上線人數都超過三十到六十人，這樣講起來上傳要拉到 3M 以上在尖峰時段才稍微堪用阿。於是整場都忙著調整 QoS 與踢掉用太多頻寬的人，中途還不小心踢掉林凱洛小姐，害她嬌驕嗔的在 Twitter 上幹譙 (我還白目的持續在不同的機器上踢了好幾次，到底是甚麼軟體會同時開一兩百個 TCP Sessions 阿)。

凱洛小姐，我把妳的 Laptop MAC Address 背起來了，不會再犯，請原諒我吧！

不過，Carol 的 Punch Party 6 有一場與毛向輝作 Skype 對談的節目，雖然直接接了有線網路，效果也相當不好，雖然當下 PP6 已經是整天活動的高潮，場內已經由於節目太嗨沒有人在上網。看來這應該是中國對台灣的網路問題，與會場的網路無關。因為下午笑談華文部落格江湖二三事議程時，喬敬用的是自己的 3G 網路與毛向輝作 Skype 對談，語音效果也不佳。

檢討與改建

  • 應該認真分析、預估鄉民的行為與需求，一點都不能大意阿。
  • 種活動，下次或許可以直接租用學術單位的會議室，這樣可以借用現成的網路基礎建設。會議前一天才拉好臨時線路，實在令人劈劈挫。
  • 要先跟各場主持人講清楚需求，像是需要現場作 Y!Live/Skype 等需要高優先值的流量。可以先設定起 QoS，將優先值調到最高。
  • 對外的機器應該準備一台 PC 或更換開放原碼軔體的機器，這樣才方便臨時作最佳化修改與監測現場狀態。每一台 AP 應該先內建 Management Agent，不要當下才切換網路各台連入設定。

另外，萬一覺得 BoF 網路不好用，完全是我錯估情勢的錯阿。陳力完全是看了這篇被騙的。Orz

若是要對我砍劈或指教，請報名免費的 COSCUP 2008，我將於 8/24 09:30-10:40 間分享相關經驗。

補充附註:

CHT 臨時租用線路，目前只提供 ADSL，最高速度到 8M/640K。8M/640K 資費是 1500 + 1500 + 1000，上述 4000 元是基本費用，另加 3000 保證金。另外 電路費用+網路費用+電話費 則是以每日 1/15 計算。例如 8M/640K 一週租金大約是 (1599+500)/15*7 =~ 980 元。

光纖部份不屬一般臨時租用業務，需另外接洽中華電信二線業務人員。

以上補充作為未來活動參考之用。由於主要支出為設定費，因此請盡量申請光纖或更高速網路。

Posted on
by

2008 開放技術台灣高峰會 (Open Tech Summit Taiwan 2008) 預計於本週舉辦，根據目前的出席人員列表，有幾位我深為敬重的開發者會來台灣 (sort by letters)

當然國內的活躍開發者如 Jserv, pcman 等人也會出席。會議對話深度精彩可期，不過大約也需要足夠的背景知識與語言能力才能跟的上議程，希望不至於曲高和寡。

主辦單位是 社團法人台灣數位文化協會 (ADCT)以及開放硬體策進會（Open Hardware Initiative）主辦。籌辦團隊是 Marek Lindner 等人，主題是 “Community” (社群)。希望可以透過此會議凝聚「社群」，主辦人希望開放給任何人對社群感興趣的人參與並加入社群。這基本上是一句廢話。根據我的認知、社群是

持有相同興趣的一群人 (group of people of the same religion, race, occupation, etc, or with shared interests) 摘至 21世紀英漢漢英雙向詞典

因此你大約對開放技術 (包含硬體、軟體) 感興趣或是 Open Mind 的人才會想加入。至於整個活動從頭到尾其實都頗令人一頭霧水，雖說目標是創造出一個合作無間或互補的環境，但是若你不認識相關主辦人，根本連報名聯絡的方式都不知道(現在已經更新了)，更不用談「貢獻」。

何況社群原本就是政治詞，即使是一群人也是相同興趣但不同的目標的小圈圈出現，談「這次活動和以往國內活動最大不一樣的地方，是每個參與的人都盡自己的力量去貢獻」等共同分攤云云、開放社群的觀點未免太唱高調，過度貶低台灣本土社群。難道國內的社群運動都是單一組織人員用錢砸出來，毋需靠其他人的共同協助嗎？

主辦人之一的 Fred 寫了一篇 彼此需要的 Open Tech Summit Taiwan 2008, 開頭就為了鞭批台灣開放原碼社群的權力鬥爭亂象，痛斥國內冒用 “Open Source” 之名的邪惡廠商。不過本活動主要贊助者是華碩，也是利用自由軟體賺過水獲利的廠商之一阿。如此、如此的宣傳方式實在過度政治化。有點反胃。

只能說， Be Open Mind.

References:

Posted on
by

根據 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, 且尚有記憶體。除了角落的朋友收訊變糟外，並未造成太大的影響。

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

Posted on
by

有時候在偵測無線網路問題的時候，總想知道附近有哪些 STA 正在使用那些 AP，Kismet 可以達到這樣的目的，不過實在不太 Fancy。

Wiviz2 screenshot

為了達到相同的目的，可以使用 Nate True 的 Wi-viz2，它被設計成即時的繪出所監聽到的 AP 與 STA 之間的關係圖，因此可以見到周圍的連線狀態。原始碼位於此。舊版網址於 http://devices.natetrue.com/wiviz/。

Posted on
by

今日重新讀了 OpenWRT 中付的 qos-scripts，發現它其實高度整合了 IMQ、L7-Filter 等機制與 HFSC, SFQ, RED scheduling algorithms ，並且使用了新的 UCI 設定介面。

預設的設定是

# QoS configuration for OpenWrt

# INTERFACES:
config interface wan
	option classgroup  "Default"
	option enabled      1
	option overhead     1
	option upload       128
	option download     1024

# RULES:
config classify
	option target       "Bulk"
	option ipp2p        "all"
config classify
	option target       "Bulk"
	option layer7       "edonkey"
config classify
	option target       "Bulk"
	option layer7       "bittorrent"
config classify
	option target       "Priority"
	option ports        "22,53"
config classify
	option target       "Normal"
	option proto        "tcp"
	option ports        "20,21,25,80,110,443,993,995"
config classify
	option target       "Express"
	option ports        "5190"
config default
	option target       "Express"
	option proto        "udp"
	option pktsize      "-500"
config reclassify
	option target       "Priority"
	option proto        "icmp"
config default
	option target       "Bulk"
	option portrange    "1024-65535"
config reclassify
	option target       "Priority"
	option proto        "tcp"
	option pktsize      "-128"
	option mark         "!Bulk"
	option tcpflags     "SYN"
config reclassify
	option target       "Priority"
	option proto        "tcp"
	option pktsize      "-128"
	option mark	        "!Bulk"
	option tcpflags     "ACK"

# Don't change the stuff below unless you
# really know what it means 🙂

config classgroup "Default"
	option classes      "Priority Express Normal Bulk"
	option default      "Normal"

config class "Priority"
	option packetsize  400
	option maxsize     400
	option avgrate     10
	option priority    20
config class "Priority_down"
	option packetsize  1000
	option avgrate     10

config class "Express"
	option packetsize  1000
	option maxsize     800
	option avgrate     50
	option priority    10

config class "Normal"
	option packetsize  1500
	option packetdelay 100
	option avgrate     10
	option priority    5
config class "Normal_down"
	option avgrate     20

config class "Bulk"
	option avgrate     1
	option packetdelay 200

於是系統可以辨識使用的是哪一種協定，且 TCP ACK 跟 SYN 會有比較高的優先值，因此使用非下載的協定如 TELNET 等反應速度會比較快。而 ICMP、ssh、DNS 等協定會有比較高的優先值，接下來是常用的網頁、電子郵件等服務。而 P2P 如 eDonkey, BitTorrent 與其他協定則只能排在最低的優先次序。如此即便上網同時養動物，也可以避免影響到一般的網頁瀏覽與電子郵件使用。

如此的實做跟一般裝在 Windows 系統上的 cFosSpeed (cFosSpeed 原理中文說明) 為異曲同工。跟前幾天見到 Mobile01 上的 AXIMCom P2P Gear 討論 以及 Lantech WL54G-MIMO BR 的討論，應該也是使用相同的技術與原理。FON 所銷售的 Fonera 是基於 OpenWRT 開發，其實也使用同樣的技術來作 QoS，因此若在 User Zone 啟用了這樣的機制，就不用擔心透過 Public ESSID 使用 P2P 軟體所造成的頻寬影響。

Linux 上還有一個比較簡單陽春的實做，是 Wonder Shaper，基本上原理相同，也是避免上下傳封包佔滿小水管，以便讓一般的網路連線可以正常使用。這個 Script 已經被移植到 Debian 與 OpenWRT 中。技術細節可以參考 Linux Advanced Routing & Traffic Control。

Posted on
by

方才讀了 Florian Fainelli 的 OpenWRT 簡報，這份簡報是在今年的 Fosdem 所演講發表。這份文件應該是目前最新的 OpenWRT 簡介了，包含的概觀介紹與幾個主要的元件設計、開發與安裝。

剛想入門使用 OpenWRT 的朋友不妨參考


關於今年 FOSDEM 的相關花絮請參 Mr. Holiday 的熱血遊記阿。