今日重新讀了 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。

雖然說 ISP 擋掉 BitTorrent 是很常見的事情，但是阻擋到影響一般日常用途就實在令人非常火大啦。調查起因是我試著在凱擘(東森媒體科技)用 OpenVPN 連回幾個位在 Hinet, Seednet, TANet 的伺服器上，在其他的 ISP 使用大致沒有問題，但是使用 Kbronet 總是會斷線，而且斷線方式是小量傳輸沒問題，但若傳輸量稍高就會被切斷連線。於是出現可以 ssh over OpenVPN 勉強可登入, 但是只要一 ls 就斷線的鳥事。原本 OpenVPN 的 server port 設定是 UDP 1194，改成 TCP 1194 後便沒有斷線問題。去電客服，當然死不承認有限制頻寬擋 P2P 軟體這件事情。問題是 Kbronet 除了 擋 BitTorrent 常用的 6881-6888 外，連其他的 UDP Ports 都一併擋掉，害我無法正常使用 OpenVPN 實在很惱人。

因此拿出 iperf + wireshark 實測一下，發現若是 Port 6881-6888 使用 TCP 瞬間就會收到TCP RST injections，而 UDP 也會收到莫名其妙的 ICMP Port unreachable 封包。這也就是為什麼 OpenVPN 老是斷線的原因。也因此如果在 Kbronet 用 BT 只用預設的 688x Ports, 下載會非常緩慢。

不過 Kbronet 看來尚未進化到 Content Filtering 的程度，將 rtorrent port 改到 80，未加密的 BitTorrent Connection 在 2M/256 的線路上大約可以衝到 215 KB. 一不做二不休也就把 DHT Port 改到 53 去了。

誰應該去把 Kbronet 加進 Bad ISPs 才對。(花了數分鐘才搞懂原來 wiki 編輯帳號得去 IRC 討，偏偏 #azureus-wiki Channel 裡面沒人。)