基本上, 瞭解明誠改版歷史的網友應該都很清楚, 明誠首先改了oleg 版, 用於ASUS WL-550gE, 其後才有Tomato 版, 用於Buffalo WHR-G54S, 所以相信小峰兄的網友, 必然不至於懷疑明誠修改了Tomato, 然後套用於oleg 之上, 何苦多此一舉? 直接把Tomato 用於ASUS WL-550gE 不就結了? 若真有人如此懷疑, 未免想像力太豐富了點, 非但沒用過明誠版, 可能連Tomato FAQ 都沒有好好研讀過, 當然以上小弟都沒使用過, 不過小弟蒐集了一些資訊, 以便重點比較這兩套韌體

首先請看圖說故事, "明誠版 IP 頻寬管理 (http://www.vigorclub.com/uploads/img4774d7c98126f.jpg)" 和 "Tomato QoS View Graphs (http://www.polarcloud.com/img/ssqosg108.png)", 主選單主要不同在於明誠版將 "Basic Settings" 和 "Classification" 改為 "連線數限制" 和 "IP 頻寬管理", 次序也調換了, 明誠版的IP 頻寬管理很容易理解, 直接鎖定上下傳頻寬, 而Tomato 只管理封包的優先順序, 並且只管上傳 (Outbound/Upload), 不管下載 (Inbound/Download), 這點在 "Tomato FAQ | polarcloud.com (http://www.polarcloud.com/tomatofaq)" 已有說明, 圖片請參考 "QOS Classification (http://www.polarcloud.com/img/ssqosc108.png)", 因此兩者的方法有著極大的差異, 批評明誠這部份修改自Tomato 者可休矣, 不過以上並不代表Tomato 沒有辦法管理下載, Tomato 只是沒有提供介面, 使用者應該還是可以自行設定
Here's a detailed explanation of the default rules in QOS/Classification:
#1: WWW
Class: High
TCP Dst Port: 80,443
Transferred: 0 - 512KB
Connections that have a destination port of 80 or 443 (outbound; 80 is the standard HTTP/WWW port, 443 is the standard HTTPS port), and have transferred LESS than 512 KB of data (outbound / upload) are put in the "High" class.

This makes web browsing a priority, as long as we're not uploading a big file.
...(恕刪)
Connections that travel from your computer directly to the router (the endpoint is the router) are never classified. Connections that travel from the Internet to your computer or router, but not the other way around are also not classified.
Tomato 和一般的分享器一樣, 也支援Static DHCP, 然而明誠所支援的 "IP/MAC 綁定", 作用應該是以MAC 鎖IP, 再根據IP 管理頻寬, 一般無線分享器都可以支援MAC 過濾, 但用戶可以自訂IP, 明誠版則連IP 也鎖住了, 使得MAC 白名單上的用戶就算變更IP 也難逃管制, 小弟猜測這部份應該和 "arp cache" 有關, 不過小弟擔心一旦啟用 "IP/MAC 綁定", 效能可能會大受影響, 因為每個封包都要額外檢查MAC/IP, 很消耗CPU 資源, 並不適合在大環境中使用
Inside or outside of the DHCP range will work, but it's probably better to use an address outside of the range so it doesn't get in the way.
Use static DHCP in Basic/Static DHCP. If you don't want to use static DHCP, you can still use the page by entering 00:00:00:00:00:00 as the MAC address.
至於個別 "連線數限制" 就不用多提了, Tomato 只有最大連線數的限制, 可達10240, 如果連線數滿載, 那麼以200MHz 的BCM5352 來說, 大概也跑不動了

最後小弟有點小小疑問, 在P2P 的用戶之中, 似乎對於Tomato 的滿意度頗高, 然而仔細分析Tomato 的優先權式管理, 似乎又存在著無法管理之處, 如何以管理上傳來有效控制下載? 令小弟無法理解, 反觀明誠頻寬管理版的用戶中, 實例證明某些環境存在3~4 個P2P 重度使用者而能相安無事, 雖然頻寬利用率並不理想, 但是對於宿網來說此非重點, 重點是公平, 另外, 友站討論熱絡的還有一台AXIMCom P2P Gear, 據傳介面很像Tomato, 價格卻高出明誠頻寬管理版甚多, 網友不妨多比較比較, 到底誰才有真工夫?

閒置頻寬的問題我們並不是沒有考慮過,不過多數人不多的家庭的用法大概都是在上傳的部分,我們也有針對一些我們的家庭客戶做建議性的調整,畢竟每個人的需求不太一樣.不做保障最小頻寬的部分主要是考慮到設定的複雜層度問題,而且版上討論過的頻寬管理相關設備小弟幾乎都賣過,甚至連needmaster兄開發根基於巴西防火牆的社區寬頻路由器的頻寬管理小弟都玩過.我們內部討論的結果,我們一致認為易用性和可用性可能才是王道.所以我們捨棄一般ip+port base的qos做法,也沒有採用如bm26或是QNO的保障最小限制最大的做法.

這幾年來,如何做到簡單有效的頻寬管理一直是我們在研究的課題.我們目前有些相關的技術在申請專利中,如果速度夠快的話,今年我們應該就會有新產品採用一些有效利用頻寬的QOS技術了.

我們的IP和MAC強制綁訂和SESSIONS都是花了不少心思的,不用擔心效能的問題.以SESSIONS限制來說,目前市面上有類似功能的產品多半是每個IP一條規則的做法,我們的寫法是一組規則內的IP都算一條規則,兩者號用機器的CPU會差距很大.IP和MAC強制綁訂也不需要在每一個封包上檢查,我們有更有效率的方式.

小弟也不知道WRT為何不開啟更高的連線數量,不過小弟知道WRT系列的韌體在BURST SESSIONS的速度太快的時候,CPU也會滿載,有時會導致WATCH DOG發現機器無回應而REBOOT.對機器來說瓶頸在於SESSIONS內的封包量和建立SESSIONS的速度,並不是SESSIONS的總數量喔!

別鬧了! connlimit 只限於 TCP 連線, 照您原本的敘述, 不大多是 UDP 連線嘛?
小弟瞭解Linux Kernel 2.4 的 Connlimit 主要針對TCP 封包, UDP 封包只能限制每秒連線數, 但是請問以下這行是否可以限制TCP 以外 (UDP+ICMP?) 的連線數? 原文出處 (http://www.linksysinfo.org/forums/showthread.php?t=54891)
iptables -I FORWARD -m iprange --src-range 192.168.22.10-192.168.22.250 -p ! tcp -m connlimit --connlimit-above 105 -j DROP
Script Generator? 還是玩具一個, connlimit 沒有辦法處理 tcp 以外的連線
能否請您評論一下這篇#8 (http://bbs.et8.net/bbs/showthread.php?t=907762) (簡體) 和這篇#9 (http://www.linksysinfo.org/forums/showthread.php?t=42296) 所使用的腳本可行性? 尤其是其中提到可以限制上下載, 甚至保證頻寬 (rate) 和最大頻寬 (ceil), 不知是否真有那麼神奇? 或者可以修改得更好? 謝謝

WRT54 Script Generator (http://openlinksys.info/firmware/przydatne/generator.zip) 或許並不完美, 但所謂 "萬事起頭難", 對於什麼都沒有, 甚至完全不熟悉iptables & tc 的網友來說, 或許可以做為一個好的開始

小弟瞭解Linux Kernel 2.4 的 Connlimit 主要針對TCP 封包, UDP 封包只能限制每秒連線數, 但是請問以下這行是否可以限制TCP 以外 (UDP+ICMP?) 的連線數? 原文出處 (http://www.linksysinfo.org/forums/showthread.php?t=54891)
iptables -I FORWARD -m iprange --src-range 192.168.22.10-192.168.22.250 -p ! tcp -m connlimit --connlimit-above 105 -j DROP

-m connlimit -p ! tcp 這是有問題的, 根本就沒辦法用...


能否請您評論一下這篇#8 (http://bbs.et8.net/bbs/showthread.php?t=907762) (簡體) 和這篇#9 (http://www.linksysinfo.org/forums/showthread.php?t=42296) 所使用的腳本可行性? 尤其是其中提到可以限制上下載, 甚至保證頻寬 (rate) 和最大頻寬 (ceil), 不知是否真有那麼神奇? 或者可以修改得更好? 謝謝


rate/ceil 這是在 TBF 裡面的功能, 是真那麼神奇, 不過設定也要正確
否則也是....

簡體的基本上連執行都有問題, iptables 不允許在一條規則內 -m(match) 兩次
而他們要限制 UDP, 是使用 -m limit, 但是, 要把 TCP and UDP, ... 通通算在一起呀..
若我要 TCP + UDP 一共 200, 請問用 connlimit + limit 要怎麼寫!? :lovely:

這些腳本, 您可以試看看, 效能是如何, 中間還有很多問題存在機器上
不過我想他們應該都沒有試過這機器的極限


WRT54 Script Generator (http://openlinksys.info/firmware/przydatne/generator.zip) 或許並不完美, 但所謂 "萬事起頭難", 對於什麼都沒有, 甚至完全不熟悉iptables & tc 的網友來說, 或許可以做為一個好的開始

但是沒有 WEB UI 介面 @@, 這些東西還不須要到使用 script generator
問題在於對 iptables & tc 的整體了解到什麼地方
按指令大家都會, 那沒什麼

簡體的基本上連執行都有問題, iptables 不允許在一條規則內 -m(match) 兩次
iptables man file - administration tool for IPv4 packet filtering and NAT : OpenSourceManuals.org (http://www.opensourcemanuals.org/manual/iptables/)
MATCH EXTENSIONS
iptables can use extended packet matching modules. These are loaded in two ways: implicitly, when -p or --protocol is specified, or with the -m or --match options, followed by the matching module name; after these, various extra command line options become available, depending on the specific module. You can specify multiple extended match modules in one line, and you can use the -h or --help options after the module has been specified to receive help specific to that module.
而他們要限制 UDP, 是使用 -m limit, 但是, 要把 TCP and UDP, ... 通通算在一起呀..
若我要 TCP + UDP 一共 200, 請問用 connlimit + limit 要怎麼寫!? :lovely:

"-m limit --limit rate --limit-burst number" 似乎不是用來控制頻寬的, 用法可以參考 "Linux 2.4 Packet Filtering HOWTO: 使用 iptables (http://www.netfilter.org/documentation/HOWTO/cn/packet-filtering-HOWTO-7.html)", 所以WRT54 Script Generator 作者可能有所誤解, UDP 仍然無解, 神話破滅!

雖然小弟還不能瞭解其作用, 不過基本上只用iptables 標記和限制連線, tc 才是用來限制頻寬, 雖然才幾行, 但是已經超出小弟的能力範圍, 等有時間再慢慢研究, 多謝指點

2.6:
iptables -A FORWARD -m limit --limit 1000 -m conntrack --ctstate DNAT -j ACCEPT ok

2.4:
iptables -A FORWARD -m limit --limit 1000 -m conntrack --ctstate DNAT -j ACCEPT ok


兩者都是 OK 的, 這是我的錯, 抱歉~

-m limit --limit rate --limit-burst number 不是拿來管頻寬用的

基本上他們的用法是:

1. iptables 設 MARK
2. tc 看 IP 或 MARK 來決定 QoS 規則

能否勞駕拉登長官試一下那個有問題的指令? "-p ! tcp" 語法是合法的, 小弟也知道connlimit 只處理tcp, 雖然兩者湊在一起並不合理, 但是小弟很好奇到底會激盪出什麼樣的火花? 否則何以兩位Linksysinfo 網友附和說有用, 甚至該篇也被收入Linksysinfo 的Tomato FAQ #8 (http://www.linksysinfo.org/forums/showpost.php?p=296648&postcount=8) 之中?

小弟的期望是, 看起來Linux Kernel 2.4 只欠缺限制udp 連線數, 姑且不論平價分享器的效能如何, iptables + tc 似乎是一個可行的方式, 如果能夠先產生一個理論正確的腳本, 再慢慢最佳化, 就算沒辦法套用到一般分享器, 但是或許有機會用於DIY 路由器

能否勞駕拉登長官試一下那個有問題的指令? "-p ! tcp" 語法是合法的, 小弟也知道connlimit 只處理tcp, 雖然兩者湊在一起並不合理, 但是小弟很好奇到底會激盪出什麼樣的火花? 否則何以兩位Linksysinfo 網友附和說有用, 甚至該篇也被收入Linksysinfo 的Tomato FAQ #8 (http://www.linksysinfo.org/forums/showpost.php?p=296648&postcount=8) 之中?


2.6 的 connlimit 是可以的(剛看了一下原始碼), 但是 2.4 的不能用於 TCP 以外的連線

2.6 的 connlimit 是可以的(剛看了一下原始碼), 但是 2.4 的不能用於 TCP 以外的連線
意思就是不必那麼麻煩, 直接 "-p all -m connlimit --connlimit-above number -j DROP" 就解決連線數了, 可惜印象中, 目前第三方韌體受限於Broadcom 所提供的無線驅動程式和Linux Kernel 2.6 不太合, 所以才繼續採用Linux Kernel 2.4, 但是沒注意Tomato 1.17 採用哪個版本的核心, 應該看cat /proc/kmsg 就看得出來才對, 小弟的懷疑是或許Tomato 修改了Connlimit Module, 所以才沒有出問題, 這也不是不可能