phần mềm xử lý sự cố bộ định tuyến dd-wrt

Tôi đã sử dụng phần mềm dd-wrt trên bộ định tuyến của mình và tôi rất thích nó!

Nhưng - tôi không chắc chất lượng dịch vụ (QoS) đang hoạt động trên đó. Tôi có nó được thiết lập như sau:

• http, cổng 80 - Cao cấp
• bittorrent, cổng 6969 - Số lượng lớn
• https, cổng 443 - Cao cấp
• dns, cổng 53 - Premium

Theo tài liệu QoS , các cấp độ này là:

băng thông được phân bổ dựa trên tỷ lệ phần trăm sau của các giá trị đường lên và đường xuống cho mỗi lớp:

• Miễn trừ: 100mbps - bỏ qua các giới hạn toàn cầu.
• Phí bảo hiểm: 75% - 100%
• Thể hiện: 15% - 100%
• Tiêu chuẩn: 10% - 100%
• Số lượng lớn: 1,5% - 100%

Điều này dường như không hoàn toàn hoạt động, mặc dù - với những dòng chảy bận rộn, tôi sẽ nhận được những điểm dừng lớn trong trình duyệt web của mình.

Các tài liệu QoS đưa ra một số bước để kiểm tra QoS ...

Những gì bạn sẽ quan tâm sẽ xem xét là tập hợp IP nguồn và đích đầu tiên, bao gồm cả số cổng. Tiếp theo sự hiện diện của l7proto và trường "mark". Các mục nhập cho biết mức độ ưu tiên QoS kết nối trực tiếp hiện tại được áp dụng trên chúng dựa trên trường "đánh dấu". Các giá trị "đánh dấu" tương ứng với các giá trị sau

• Miễn: 100
• Phí bảo hiểm: 10
• Thể hiện: 20
• Tiêu chuẩn: 30
• Số lượng lớn: 40
• (không có QoS phù hợp): 0

Bạn có thể thấy "mark = 0" cho một số dịch vụ l7proto mặc dù chúng được cấu hình trong danh sách các quy tắc QoS. Điều này có thể có nghĩa là hệ thống khớp mẫu lớp 7 không khớp với tiêu đề mới hoặc đã thay đổi cho giao thức đó. Dịch vụ tùy chỉnh trên các trận đấu cổng thường sẽ chăm sóc những điều này.

Trên cổng 6969 (bittorrent) tôi thấy một hỗn hợp kỳ lạ của những thứ với mark=0và mark=40như vậy

mèo / Proc / net / ip_conntrack

udp 17 105 src = 98.162.182.42 dst = 1.2.3.4 sport = 64512 dport = 6969 gói = 3 byte = 290 src = 10.0.0.2 dst = 98.162.182.42 sport = 6969 dport = 64512 gói = 4 byte = 202 [ASSURED] đánh dấu = 0 giây = 0 sử dụng = 1
tcp 6 117 TIME_WAIT src = 98.248.173.174 dst = 1.2.3.4 sport = 51114 dport = 6969 gói = 12 byte = 704 src = 10.0.0.2 dst = 98.248.173.174 sport = 6969 dport = 51114 gói = 10 byte = 440 ] mark = 40 secmark = 0 use = 1
tcp 6 598 THÀNH LẬP src = 165.132.128.201 dst = 1.2.3.4 sport = 57218 dport = 6969 gói = 8024 byte = 9919881 src = 10.0.0.2 dst = 165.132.128.201 sport = 6969 dport = 57218 ] mark = 0 secmark = 0 use = 1
tcp 6 586 THÀNH LẬP src = 68.46.9.24 dst = 1.2.3.4 sport = 64688 dport = 6969 gói = 6 byte = 490 src = 10.0.0.2 dst = 68.46.9.24 sport = 6969 dport = 64688 gói = 8 byte = 944 [ASSURED ] mark = 40 secmark = 0 use = 1
udp 17 45 src = 222.254.228,38 dst = 1.2.3.4 sport = 25438 dport = 6969 gói = 5 byte = 454 src = 10.0.0.2 dst = 222.254.228,38 sport = 6969 dport = 25438 gói = 3 byte = 154 [ASSURED] đánh dấu = 0 giây = 0 sử dụng = 1

(tập tin đầy đủ hiển thị tại http://pastebin.com/AZE6EtWm )

Tôi đã chơi xung quanh với nhật ký này một lúc và tôi không thể thấy bất kỳ mẫu nào!

Tại sao một số cổng 6969 lưu lượng truy cập bittorrent được gắn thẻ mark=0(không khớp) bởi QoS của dd-wrt trong khi các cổng khác được gắn thẻ mark=40(Hàng loạt) .. có ý tưởng nào không?

Mặc dù nó chỉ định hình lưu lượng đi , nhưng bạn có thể thấy tập lệnh QoS tuyệt vời này ( phản chiếu trên pastebin ) trên blog của Alex Rice hữu ích. Đó là thông qua một số tác giả và hóa thân. Hãy chắc chắn để đặt UPLINK cũng như DEV chính xác. Đối với tôi, giá trị mặc định cho DEV là không chính xác, $(nvram get wan_ifname)thay vào đó hãy sử dụng nhận xét hoặc giá trị chính xác từ việc thực thi nvram get wan_iframethông qua SSH.

Ngoài ra, thay vì sử dụng nó, bạn có thể sao chép cấu hình của nó trong GUI QoS. Bạn sẽ thấy nó sử dụng 1024: 65535 cho lưu lượng truy cập lớn, với các cài đặt khác (80,22,3389, v.v.) được ưu tiên. Kịch bản hoạt động tốt với tôi và sử dụng HFSC theo khuyến nghị.

Ví dụ: QoS được đặt thành WAN gửi lưu lượng đường lên tới hàng đợi đường xuống
Sau đó nhận ra bản vá này không thành công, bởi vì: Các lệnh trong tập lệnh RC_firewall không được áp dụng trong QoS

Bạn có thể giải quyết vấn đề với một tập lệnh thực thi sau RC_firewall như được ghi trong vé. Cá nhân tôi đã kết thúc việc kích hoạt JFFS và đặt tập lệnh với bản sửa lỗi /jffs/etc/config/qos.ipup, giống như đã đề cập.

Tôi thấy thuận tiện khi sử dụng KiTTY và WinSCP . Bạn có thể SSH vào bộ định tuyến bằng KiTTY để khắc phục sự cố / xác minh như trong vé đầu tiên và khởi chạy thẳng vào trình duyệt tệp trên bộ định tuyến bằng Start WinSCPlệnh dưới biểu tượng trên cùng bên trái của KiTTY. Nếu điều này không thành công (bộ định tuyến không chạy SFTP theo mặc định), bạn có thể bật FTP và kết nối thủ công hoặc chỉ cần thêm tệp bằng các lệnh Unix. Hãy nhớ đặt quyền thực thi của chủ sở hữu trên tập lệnh.

Tôi đã nhận thấy rằng rất nhiều người phàn nàn về QoS không hoạt động trong DD-WRT, vì vậy họ chuyển sang Tomato thay thế. Nó hoạt động tốt trong cà chua (tôi sử dụng nó). Cà chua cũng có các biểu đồ rất đẹp, rất hữu ích để điều chỉnh cài đặt QoS của bạn.

Nhược điểm của Tomato, so với DD-WRT, là nó có ít tính năng hơn, mặc dù có một số bản dựng mod bổ sung một số thứ nhất định, như bộ lưu trữ USB và OpenVPN. Tuy nhiên, như Jeff Atwood đã đề cập dưới đây, nó chỉ hỗ trợ chipset Broadcom.

Tôi sử dụng mod Teddy Bear trên Netgear WNR3500L của tôi. Bây giờ tôi sử dụng mod Toastman, dựa trên Teddy Bear, với nhiều tính năng hơn và các lớp QoS mặc định tốt hơn, hoạt động cho hầu hết mọi người.

Cá nhân, điều duy nhất tôi thiếu trong Tomato là hỗ trợ Vlan và phát đa SSID. (Mod của Toastman hiện có cả hai, cũng như Captive Portal cho SSID thứ cấp).

Tôi đã tìm thấy DD-WRT v24 sp2 build 15362 hoạt động rất ổn định trên Netgear WNDR3700 v1 BUT của tôi mặc dù đã dành một lượng lớn thời gian để cố gắng thiết lập cả QoS và TCP Vegas (điều khiển tắc nghẽn) không có cơ chế nào hoạt động trên phần mềm tuyệt vời này đối với lưu lượng truy cập trong nước (Tôi không có nhu cầu kiểm soát ra ngoài vì tôi không sử dụng VOIP).

Ví dụ: bất kể tùy chọn nào (Mac Control, Netmask, Service Control) tôi sử dụng trong các nỗ lực của mình để ưu tiên lưu lượng truy cập video trong nước và không ưu tiên lưu lượng truy cập torrent bit trong nước không có gì hoạt động. Tôi đã xác nhận điều này với

• Các lệnh Telnet được đề xuất để xác nhận hoạt động QoS
• TCP Vegas

Tóm lại: Sử dụng DD-WRT nếu bạn muốn tất cả các tính năng khác (đặc biệt là phát SSID trung gian) nhưng sử dụng Tomato nếu bạn có chipset có thể áp dụng (Tomato không có sẵn cho WNDR3700 dựa trên Atheros) và giống như các tính năng QoS của nó.

Tôi đa ghi chu điêu tương đương. Tôi không thể tìm thấy bài đăng chính xác ngay bây giờ, nhưng đào qua các diễn đàn, một trong những nhà phát triển đã nói rằng QoS vì nó hoạt động rất tốt khi tải lên, không quá nhiều về tải xuống. Lý do đằng sau nó là bộ định tuyến có quyền kiểm soát lưu lượng đi ra khỏi mạng (đường lên), nhưng không phải lưu lượng đi vào vì nó không kiểm soát được luồng dữ liệu đến.

Tôi biết bạn không phải là một fan hâm mộ lớn của trình duyệt thông qua các bài đăng trên diễn đàn, nhưng bạn có thể muốn gửi câu hỏi của bạn ở đó.