Forum Replies Created
Has IPset been implemented yet? Also a drop down menu still would be great to have. rather than multiple single rules for the same thing.
Such as spammers. Just create one single rule, drop port 25, point the rule to an ipset. Go to the menu section for the Ipset, add the offending ips to the Spammers Ipset.
I’d like nDPI part of Zeroshell as well.
Some links to what CoDel can do and is capable of.
Yes, use the string/algo method instead, it’s a much more elegant solution. Thanks modti.
What was the solution? I’ve asked about this before, and never got an answer.
Sure Putty is portable. I was just making a suggestion to make administering Zeroshell easier. Combine a web-based CLI so you don’t need to rely on something else, keep it all contained and streamlined, and if wanted to use Putty.
Rda – Do you think you’d be able to take this and make it like your compilation in “http://www.zeroshell.net/eng/forum/viewtopic.php?t=2763&highlight=”, and also add hashspeed, so that your packages of opendpi, xtables, ipp2p, tcp rst, ipset, and hashspeed are all included?
I’ll repost this on zshare
Zshare seemed faster on downloading, around 4Mbit/sec
I agree to add comments-capability. Makes sense when having hundreds to thousands of rules. It’s one thing to be the only admin, but another to have multiples and everyone having their hands on changes and no comments on the rules.
Just putting it out there, haven’t tried it though…
Turn off SSH access in the setup, then add the firewall rule as rule #1. That way it will be on top, just a guess.
You can not make a single rule that will state each ip in a subnet to get a certain speed of it’s own. Any rule that has a class attached to it, and a subnet, the entire subnet will share the single class. Currently there is no way to make a single rule that states 192.168.1.0/24 each ip gets 256k.
Currently you’d need to make a separate rule for each ip, actually two rules, one for upload, and one for download speeds. Which is very time consuming, tedious, and not scalable really. Though zeroshell is great in all other shaping needs, this on feature request would be great to have. I’ve already put in a request a while back.
This can happen though for limiting packets per second with the hashlimit mode. This hashlimit will limit all source ips in a subnet to a set amount of pps, say all ips in 192.168.1.0/24 will get their own rule for 50pps.
Someone modded this and made something called hashspeed (Google it). You will only need two rules for this one for the entire subnet. It is the same concept, except modded for both source and destination and for rate rather than pps. So in one rule you can have source 192.168.1.0/24 256k for upload, and all ips will have their own virtual separate qos rule, all in one rule. And the same but for destination for download. Pretty slick.
My stats are:
CPU ( 4) Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz 2400MHz Refresh
Uptime 146 days, 5:45
Load Avg 0.03 0.03 0.00 Graphics
Memory 2050568 kB
Less than 3% CPU usually, 200Megs ram used on average, MAX 56k (57,000) concurrent connections, with peaks of 110Mb/s download 38Mb/s upload, on an Interface Masters N2265, and a basic on-board NIC for management.
Works out very very well. 61 Firewall rules, 65 QoS rules.
Here is some documentation on this patching the kernel for support on this. Calls for replacing all calls of the original tc utility in any scripts that call for it, with the newly-patched tc-esfq version. This would be such a nice addition please, or any feedback/comments.
From some reading esfq is really used any more, only sfq is. Sfq allocates bandwidth in a class evenly amongst individual connections, the default linux way.
This script implements esfq’s support by using sfq with an external classifier.
An example of using this method, a class of 5megs download, with only two people using it, one person with 4 connections active, say 4 ftp download sessions, and the other person only has 1 ftp session active, the class will be evenly distributed amongst 5, so 1meg per the 5 connections.
Which is correct for the way sfq works, but is not “fair” to a human sense. It should be based on src/dst.
If the cls_flow module could be implemented, and state flow hash keys dst, then the bandwidth will be distributed based on the dst ip rather than by single connections, evenly distributing the bandwidth into 2 of 2.5megs each per person, resulting in fairness.
When more people get put into the class, say 8 more, making a total of 10 people, the 5meg class gets divided by 10, and turns into 512k per person, until the person stops talking, then that 512k goes back into the class for the others to use, and dynamically changes as needed.
In beta 14 you can do “modprobe cls_flow” and it shows up in lsmod as loaded, but when using the command of “tc filter add flow help” to get qa basic flow help, you get “Unknown filter “flow”, hence option “help” is unparsable. Perhaps it needs to be loaded in a preboot script, prior to QoS loading?
Any help would be appreciated, as this would make distributing bandwidth in a class much more efficient and fair. Too many people using p2p in a class with just basic sfq would ruin a class because of all of the connections it builds up, making the class useless for the other people. If based on cls_flow, all people would get their divided share fairly, and evenly.