Download
cFosSpeed Filter Expressions
Overview
cFosSpeed supports a number of different traffic classes set to different priorities. In effect, this means packets in classes with a higher priority are sent out prior to packets from classes with lower priority - even if low-priority packets arrive before high-class packets in their respective class queues.
That way, cFosSpeed can prioritize specific packets permitting them to take the "fast lane" and zip past "normal" traffic. This priority system can be modified and expanded by the user with what we call "filter expressions." These can be used to filter out packets and assign them to a desired traffic class.
Filter expressions consist of a series of "filter rules" that all need to be true for the entire expression to be true. If the entire expression is true, the packet is put into the corresponding class queue.
A list of filter expressions does allow you to filter for several different packets. This list is checked from top to bottom; the first filter expression found to be true (i.e., consisting only of true filter rules) is employed, ending list traversal.
Packets not matching any particular filter expression are automatically assigned to the "default" class, which is a built-in class with priority 0.
A silly and simple example
A sample list of filter expressions is given below (the output looks like the "spd filter" output described later in this overview). Note that this sample is provided for illustration purposes only; it has no other use.
0 -p icmp -c fast 1 -tcp-sport 1234 -tcp-dport 5678 -c special
This would mean that if a packet is of IP protocol "icmp", it would be assigned to "fast" class, ending traversal of the list.
If a packet does not match the first expression, then it will be checked for the second expression. In this case, the latter consists of two rules, which must both be true for the entire expression to be true (a boolean AND).
The "-tcp-sport" entry checks the TCP source port number. Accordingy, for this sample rule to be true, the packet must have IP protocol "tcp" and the tcp source port must be 1234.
Then, there is rule 2, which is true if (again) it's a tcp packet and the tcp destination port is 5678.
Thus, all tcp traffic transmitted from port 1234 to port 5678 would be assigned to "special" class.
If neither of the two rules apply to the packet (which should happen fairly often), it would be put into "default" class instead.
Filter rules reference
Now let's go into more detail.
Each rule can be negated by preceding it with a '!' (exclamation mark) or by putting the '!' in between the option name and value (if such a value does exist). So it has to be "!-f", but you could also use "!-p icmp" or "-p !icmp".
Underlying most rules are one or more implicit assumptions; for instance, -tcp-length assumes it's a tcp packet after all. These assumptions are listed with each rule. If a packet does not match the assumptions, the rule is false. Note that the rule would be false even if you negated it (by using '!').
That is, a !-tcp-length 0 rule would match TCP packets of any length other than zero, but would not match any non-tcp packet.
If you need to specify a number, you can enter the number either in decimal (just type it in as is) or hexadecimal (prefix it with "0x") format. For example, 16 and 0x10 both denote decimal number 16.
For some rules, a range of values can be entered. Allowable value ranges are:
- num
- like "99" A single number that must be matched exactly. As usual, the number can be entered either in decimal or hex format.
- from:to
- like "42:99" Range of integers starting and including "from", while also including and ending with "to". If "from" is higher than "to", the two values are exchanged.
- :to
- like ":99" Short for "0:to"; in this example, short for "0:99".
- from:
- like "42:" Short for "from:0xffffffff".
What's more, a list of ranges can be entered for some rules. That is simply a concatenation of several ranges, separated by commas (,). For example, "1:2,3:4" is just another way of writing "1:4".
Basic rules
- -tx
- Transmit. True if the packet is sent. There is no implied
assuption with this rule.
We maintain separate lists of filters for each transmit and receive. By using this rule you specify that a filter only be put on the transmit list. Since this can't change in session, the rule is not re-evaluated each time a packet comes in; we call it a "cheap rule". - -rx
- Receive. True if the packet is received. There is no implied
assuption with this rule.
Comments of "-tx" rule apply analogous. - -wan
- Packet is transmitted on a WAN port (i.e., on NDISWANIP device) in contrast to LAN port. Is always true for cFos. There is no implied assuption with this rule. This rule is "cheap", too.
- -bridged
- Packet is transmitted on a LAN port and your modem works as a bridge, not as a router. That is, the IP subnet is not your own, but your provider's. There is no implied assuption with this rule. This rule is "cheap" only on a WAN port, since this is always considered bridged.
- -eth
- The port operates with Ethernet framing.
This is always true for cFosSpeed and always false for cFos. This rule is "cheap" and has no implied assumption. - -ethp protocols
- Ethernet protocol number.
This rule has the implied assumption that Ethernet framing is used, i.e., it is always false for cFos.
You can specify a list of ranges for "protocols". Protocol numbers may be written in decimal or hex.
Some protocol numbers are: -
- 0x800
- IP, Internet Protocol version 4
- 0x806
- ARP, Address Resolution Protocol
- -ppp
- The port operates with PPP framing.
This is always true for cFos and always false for cFosSpeed. This rule is "cheap" and has no implied assumption.
Details on PPP can be found in RFC 1661 (The Point-to-Point Protocol), www.ietf.org/rfc/rfc1661.txt. - -pppp protocols
- PPP protocol number.
This rule has the implied assumption that PPP framing is used, i.e., it is always false for cFosSpeed.
You can specify a list of ranges for "protocols". Protocol numbers may be written in decimal or hex.
Some protocol numbers are:- 0x21
- IP, Internet Protocol version 4
- 0x2d
- Van Jacobson Compressed TCP/IP
- 0x2f
- Van Jacobson Uncompressed TCP/IP
- 0xc021
- LCP
- 0x8021
- IPCP
- -mp-header
- The packet has a Multilink-PPP header.
This rule has the implied assumption that PPP framing is used, i.e., it is always false for cFosSpeed.
Details on PPP Multilink can be found in RFC 1990 (The PPP Multilink Protocol), www.ietf.org/rfc/rfc1990.txt. - -mp-begin
- The packet has the (B)eginning fragment bit set in the
Multilink header.
This rule has the implied assumption that the packet has a Multilink PPP header, i.e., the rule is always false for cFosSpeed. - -mp-end
- The packet has the (E)nding fragment bit set in the Multilink
header.
This rule has the implied assumption that the packet has a Multilink PPP header, i.e., the rule is always false for cFosSpeed. - -mp-frag
- The packet has in its Multilink header either no (B)eginning
fragment bit set, or (E)nding fragment bit set, or both.
This rule has the implied assumption that the packet has a Multilink PPP header, i.e., the rule is always false for cFosSpeed. - -rand prob chance
-
Pseudo-random number.
The rule returns true if a pseudo-random number between 1 and "prob" (borders included) is <= "chance". "prob" must be between 1 and 2^32-1, "chance" can even be 0.
The pseudo-random numbers are generated by a comparatively poor generator (LCM style). It will still look "random" enough for packet-loss tests.
- Example: This rule will be true in 5% of all cases (statistically):
- -rand 100 5
IP header filter rules
Details on the IP header can be found in RFC 791 (Internet Protocol), www.ietf.org/rfc/rfc0791.txt.
IP header filter rules apply only to IP packets with a correct checksum. These rules work on any IP packet, fragment or not.
- -s address-list
-
Source IP address.
There are several ways to specify address-list:
- adr
- like 1.2.3.4
This rule matches exactly one address with no wildcarding possible. - adr/netmask
- like 1.2.3.0/255.255.255.0
This can be used to specify an "IP subnet". The match works as follows: If the address that is to be tested AND the "netmask" are equal to "adr", then there is a match, otherwise not. This works just like IP routing rules. - adr/bits
- like 1.2.3.0/24
This is an alternative form of the adr/netmask approach above. Here, "bits" refer to the number of "1" bits, starting at the left of a 32-bit number. Thus, "/24" would be 24 1-bits and eight 0-bits. In the regular format separated by dots, this would come out as 255.255.255.0 (since 255 is 11111111 in binary code). - adr,adr...
- like 1.2.3.0/24,4.5.6.7,8.9.0.0/255.255.0.0
You can make a list of any of the above used notations. Don't leave any spaces and separate the items with a comma (',').
- -d address-list
- Destination IP address, where "address-list" has the same format as explained for the -s filter.
- -p protocol
-
IP protocol, where "protocol" is either a decimal or hex number
or one of the following hard-coded names:
- ICMP
- protocol number 1
- IGMP
- protocol number 2
- TCP
- protocol number 6
- UDP
- protocol number 17
- GRE
- protocol number 47
- ESP
- protocol number 50
- AH
- protocol number 51
- -f
- IP datagram is not the first fragment (that is, the IP header field "fragmentation offset" is not equal to 0).
- -mf
- "More Fragments" bit in IP header set.
- -fragment
- Datagram is not a complete IP frame, but a fragment. That is, either "fragmentation offset" is not 0 or the "More Fragments" is set.
- -df
- "Don't Fragment" bit in IP header set.
- -tos type-of-service
- Type of service.
"type-of-service" can be any decimal or hex number between 0 and 255. Note that TOS is neither used nor supported much any more. For details, see RFC 1349 (Type of Service, www.ietf.org/rfc/rfc1349.txt). See -dscp option below for a modern way of interpreting the TOS field. www.iana.org/assignments/ip-parameters lists common TOS values. - -dscp dscp-value
- Differentialed Services Coding Point, an alternate way of interpreting the TOS field.
"dscp-value" can be a value between 0 and 63 or a range of such values. For details, see RFC 2474 (Differentiated Services, www.ietf.org/rfc/rfc2474.txt). See -tos option above for the traditional (now almost extinct) way of interpreting the TOS field. - -ttl ttl-value
- IP header field "Time to live".
"ttl-value" can be a range of numbers between 0 and 255. See "range" below on how to specify a range. - -length value
- Length of the IP datagram or fragment.
You can specify a range for "value", which is the length of the packet about to be send. With a fragment, it's NOT the length of the reassembled datagram but the length of the individual fragment. - -data-length value
- Length of the data portion of an IP datagram, which is the
length of the (reassembled) datagram minus the IP header
length.
You can also specify a range for "value". - -ihl value
- Length of the IP header, with values anywhere from 20 to 60. Again, you can specify a range for "value".
- -s-mynet
- The source address is in your subnet.
- -d-mynet
- The destination address is in your subnet.
- -s-bcast
- The source address is the subnet directed broadcast address.
i.e., if your subnet is 192.168.1.0 and has subnet mask
255.255.255.0, this rule will match on source address
192.168.1.255.
Note that this filter will not match the limited broadcast address 255.255.255.255. - -d-bcast
- The destination address is the subnet directed broadcast address. See -s-bcast for more info.
- -s-iplist list
- The source address is listed in the iplist named 'list'. For more on iplist's see "IP-range lists".
- -d-iplist list
- The destination address is listed in the iplist named 'list'. For more on iplist's see "IP-range lists".
- -ip-opt list
- Packet has at least one of the listed IP-options in its header. The options can be set in decimal or hex and are separated with a comma, like "131,137". A list of IP-options is here: www.iana.org/assignments/ip-parameters
UDP header filter rules
Details on the UDP header can be found in RFC 768 (User Datagram Protocol, www.ietf.org/rfc/rfc0768.txt). Note that each UDP header is prefixed by an IP header, since UDP needs IP for transmission.
UDP header filter rules apply only to packets with correct IP header checksum, UDP-protocol set, and correct UDP-header checksum. In addition, they must either be unfragmented or the last fragment that completes the reassembled datagram.
- -udp-sport ports
- UDP source-port number, or a range of several such ports, or
a list of ranges (see above on how to specify them).
A UDP connection is identified by the following four values: source IP address, source UDP port number, destination IP address, and destination UDP port number. So, whenever you send a UDP packet from A to B, the packet always contains those four values.
Since these filter rules are only used for outgoing data packets, "source port" always refers to the port number of the connection on your (local) side. - -udp-dport ports
- UDP destination-port number, or a range of several such
ports, or a list of ranges (see above on how to specify
them).
See -udp-sport for more on port numbers.
Since these filter rules are only used for outgoing data packets, "destination port" always refers to the port number of the connection on the remote side. - -udp-lport ports
- Local UDP port number, or a range of several such
ports, or a list of ranges (see above on how to specify
them).
See -udp-sport for more on port numbers. - -udp-lport ports
- Remote UDP port number, or a range of several such
ports, or a list of ranges (see above on how to specify
them).
See -udp-sport for more on port numbers. - -udp-length value
- Length of the UDP data portion as mentioned in the UDP
header.
Since the UDP header is measured in "value", even the smallest UDP packet possible would have a length of 8. Note that this is different from the concept of -tcp-length (see below). - -udp-prog programnames
- Name of the program that sent the datagram.
Note: This only works starting with Windows XP and it only works if the program is running on the same machine as cFosSpeed is (that is, it does not work if cFosSpeed is used on a router and the program is running on a client).
"programnames" can be:- program name
- Must be a full file name with extension, but no path (like ftp.exe). Case does not matter. If the program name includes a space, put it in quotes (like "the best.exe").
- @section name
- The name of a section in settings.ini that contains names of programs (like @lowprogs with a [lowprogs] section somewhere is settings.ini).
- @file/section name
- The name of a section in "file". "file" can be a fully specified pathname or "user.ini" to specify user.ini in cFosSpeed directory. The handling is otherwise like that of "@section" above.
- list
- A comma delimited form of the above. There must be no spaces
before or after the commas. Example: ftp.exe,telnet.exe,"the
best.exe",@lowprogs
See "Managing program names" later on how to manage keys in sections.
TCP header filter rules
Details on the TCP header can be found in RFC 793 (Transmission Control Protocol, www.ietf.org/rfc/rfc0793.txt). Note that each TCP header is prefixed by an IP header, since TCP needs IP for transmission.
TCP header filter rules apply only to packets with correct IP header checksum, and TCP protocol set. They must be either unfragmented or the last fragment that completes the reassembled datagram.
- -tcp-sport ports
- TCP source port number, or a range of them, or a list of
ranges (see above on how to specify them).
A TCP connection is identified by the following four values: source IP address, source TCP port number, destination IP address, and destination TCP port number. So, whenever you send a TCP packet from A to B, the packet always contains those four values.
Since these filter rules are only used for outgoing data packets, "source port" always refers to the port number of the connection on your (local) side. - -tcp-dport ports
- TCP destination port number, or a range of several such
ports, or a list of ranges (see above on how to specify
them).
See -tcp-sport for more on port numbers.
Since these filter rules are only used for outgoing data packets, "destination port" always refers to the port number of the connection on the remote side. - -tcp-lport ports
- Local TCP port number, or a range of several such
ports, or a list of ranges (see above on how to specify
them).
See -tcp-sport for more on port numbers. - -tcp-rport ports
- Remote TCP port number, or a range of several such
ports, or a list of ranges (see above on how to specify
them).
See -tcp-sport for more on port numbers. - -tcp-length value
- Length of the TCP data portion, also know as the "TCP
segment."
In contrast to the concept of -udp-length or -icmp-length, this does NOT include TCP header length, meaning that the smallest TCP packet possible would have a -tcp-length of 0. - -thl value
- TCP header length, with values anywhere from 20 to 60. You can also specify a range for "value".
- -tcp-flags mask result
-
Check for the presence of certain flags in the TCP header.
The value of the TCP flags in the header are ANDed with "mask" and the packet is matched if that equals "result". Both "mask" and "result" must be specified as a list of flags. Recognizable flags are: FIN, SYN, RST, PSH, ACK, and URG. ALL stands for all six of them and NONE for none.
- Examples:
- -tcp-flags SYN SYN
- means: if the SYN bit is set (regardless of the other bits), then it matches.
- -tcp-flags ALL SYN
- means: if only the SYN bit is set and all others are zero, then it's a match.
- -tcp-flags SYN,ACK ACK
- means: if SYN is not set and ACK is set, we have a match.
- -tcp-flags URG,PSH NONE
- means: if neither URG nor PSH are set, it's a match.
- -syn
- Synonymous for "-tcp-flags SYN,RST,ACK SYN", meaning it only matches the first packet in the TCP three-way-handshake.
- -tcp-prog programnames
- Name of the program that sent the segment.
Note: This only works starting with Windows XP and it only works if the program is running on the same machine as cFosSpeed is (that is, it does not work if cFosSpeed is used on a router and the program is running on a client).
To learn how to specify "programnames" see -udp-prog rule. - -tcp-connections range
- Number of total TCP connections is in "range". Half-open connections are counted as well. The number of connections doesn't need to exactly match either side's count, since cFosSpeed uses its own TCP connection tracking.
- -tcp-opt list
- Packet has at least one of the listed options in its TCP header. The comments of "-ip-opt" apply. A list of TCP-options is here: www.iana.org/assignments/tcp-parameters
- -tcp-session value
-
Packet is part of a TCP connection that is in state "value".
Possible states are:
- 0
- A TCB has been created
- 1
- At least one side has sent a SYN
- 2
- Both sides have sent SYNs
- 3
- Both sides have sent SYNs that have been ACKed: connection established
- 4
- At least one side has sent a FIN
- 5
- Both sides have sent FINs
- 6
- Both sides have sent FINs that have been ACKed: connection closed
- 7
- At least one side has sent a RST
- -tcp-session-dadr value
- There is a TCP connection is state "value" between the same
source and destination address as this packet.
Possible states are the same as listed under "-tcp-session".
This rule only implies that the packet is a valid IP packet, but not necessarily TCP. - -tcp-initiated direction
- Check which side initiated the TCP connection.
"tx" means that the first SYN was sent, "rx" that the first SYN was received from the net. - -tcp-seq range
- TCP sequence number (subtracted by the initial sequence
number) on the particular TCP connection.
TCP keeps your sent data in sequence. So even if packets get lost, corrupted or out of order on the way from source to destination host, TCP will get it right for you (yeah!). Do achieve this, TCP packets have a sequence number, so TCP knows the correct order of them. This sequence number is increased with every byte that is transmitted on the connection.
The filter rule lets you use the sequence number as a means of how many bytes have been transmitted on the connection.
"range" can be a range of numbers.
I.e. "-tcp-seq :500" will only match TCP packets that cover the first 501 bytes in their connection (0 to 500, inclusive). - -tcp-cnt range
- TCP packet counter for this particular connection.
This counter is increased by one with each packet sent.
UDP and TCP combo rules
Sometimes you have to specify the same rules for UDP and TCP ports. This can be done by the following combo rules.
The assumptions for UDP and TCP packets each still apply.
- -sport ports
- If it's a UDP packet, synonymous for "-udp-sport ports"; if it's a TCP packet, synonymous for "-tcp-sport ports". Otherwise, there is no match.
- -dport ports
- If it's a UDP packet, synonymous for "-udp-dport ports"; if it's a TCP packet, synonymous for "-tcp-dport ports". Otherwise, there is no match.
- -lport ports
- If it's a UDP packet, synonymous for "-udp-lport ports"; if it's a TCP packet, synonymous for "-tcp-lport ports". Otherwise, there is no match.
- -rport ports
- If it's a UDP packet, synonymous for "-udp-rport ports"; if it's a TCP packet, synonymous for "-tcp-rport ports". Otherwise, there is no match.
- -prog programnames
- Name of the program that sent the segment.
Note: This only works starting with Windows XP AND it only works if the program is running on the same machine as cFosSpeed is (that is, it does not work if cFosSpeed is used on a router and the program is running on a client).
To learn how to specify "programnames" see -udp-prog rule. - -l7-prot protnames
- Check if packet belongs to a TCP connection resp. UDP
pseudo-connection with a certain layer-7 protocol. A list of
supported layer-7 protocols is in settings.ini, sections
highprots, normalprots, lowprots and lowestprots.
For certain protocols (like IRC, Telnet, file sharing, etc.) there is a further check built in: if the rule is about to match and the class the packet will be queued into is higher than default, then the connection must not be in "bulk mode". cFosSpeed uses statistics to estimate if the connection is is bulk mode, i.e. if data is being constantly sent in large amounts. If the connection is assumed to be in bulk mode, then the -l7-prot rule does NOT match. This is to prevent protocols that can be used for both bulk and interactive transfer to clog the high classes if the protocol is in bulk mode. This auto-bulk-detection can be switched off by typing the command "spd gset bulk_detect 0".
This rule has the implied assumption that layer-7 detection is on, i.e. that global variable l7_detect is 1.
ICMP filter rules
Details on the ICMP header can be found in RFC 792 (Internet Control Message Protocol, www.ietf.org/rfc/rfc0792.txt). Note that each ICMP header is prefixed by an IP header, since ICMP needs IP for transmission.
ICMP header filter rules apply only to packets with correct IP-header checksum, ICMP protocol set, and correct ICMP checksum. Such packets must also be either unfragmented or the last fragment that completes the unfragmented datagram.
- -icmp-type type - or - -icmp-type type/code
- Check for ICMP type and code (if specified).
Both "type" and "code" can be any number between 0 and 255. If you specify no "/" and no code, it will match only on the "type" value. Otherwise, the "code" value must match as well.
You can specify a list of type or type/code as well. Use commas to separate the entries in the list. - -icmp-length value
- Length of the ICMP data portion. This is the IP datagram
length minus the IP header length.
Again, "value" can also be a range of values.
VLAN rules
Details on VLAN can be found in IEEE 802.1Q (e.g. on Wikipedia).The VLAN rules except -is-vlan only applie if the packet has a VLAN header at all.
- -is-vlan
- Matches if a packet had a VLAN header.
- -vlan-prio range
- VLAN packets have a 3 bit priority field (i.e. the priority is 0-7). If this VLAN priority is in "range", this rules matches.
- -vlan-id range
- VLAN packets also have a 12 bit ID field (i.e. 0-0xfff or 0-4095). If the ID is in "range", this rule matches.
- -highest
- This feeds packets to the "highest" class.
All cFosSpeed pings are matched by this rule. - -higher
- This feeds packets to the "higher" class.
All TCP ACKs are matched by this rule. ACK is an empty TCP packet with no RST or FIN set. - -high
- This feeds packets to the "high" class.
This rule matched all (by default) prioritized traffic: ICMP, DNS and NTP (on UPD), FTP command, POP, IMAP, Telnet, SSH, HTTP, HTTPS (on TCP). - -low
- This feeds packets to the "low" class.
- highest -prio 100 -weight 400
- Only special cFosSpeed traffic sent out to measure latency is assigned to this class. This must not be changed and there must be no other traffic going into class highest but the -highest traffic nor must there be a class with higher or same prio. If there was, cfosspeed shaping would degrade in quality. Also see -highest rule.
- higher -prio 90 -weight 400 -speed 40%,0
- This class encompasses all TCP ACK packets. See -higher rule for more. The -speed setting is to ensure that if there is a flood of TCP ACKs other packets get their share of the bandwidth as well.
- high -prio 80 -weight 400 -speed 40%,0
- This class includes different kinds of traffic that are by default prioritized; see -high rule. The -speed setting is in for the same reason than in -higher.
- low -prio 0 -speed 20%,-10 -weight 25
- This class will get FTP data and SMTP (i.e., mail) uploads. We want these types of data to be sent out only if there is no other traffic that is most likely interactive.
- lowest -prio 0 -speed 20%,-30 -weight 6
- This class gets P2P traffic and other traffic that is sent out all the time in the background. We want it to give way to ANY other traffic that is sent.
- addkey <key> <section>
- This will add the line <key> to the section <section> in settings.ini.
- delkey <key> <section>
- This will delete the <key> line from <section>.
- showsect <section>
- This will display all keys set in the named section.
- 1
- PPPoE
In spd this is called "pppoe".
This is sometimes called "RFC 1483 Bridged, PPPoE" or "RFC 2684 Bridged, PPPoE". - 2
- PPPoA, VC-multiplexed
In spd this is called "pppoa_vc_mux".
This is sometimes called "RFC 2364 VCMUX". - 3
- ISDN HDLC with or without VJ-compression
In spd this is called "isdn". - 4
- PPTP
In spd this is called "pptp". - 5
- Raw IP (with DHCP)
In spd this is called "raw_ip". - 6
- PPPoA, LLC-encapsulated
In spd this is called "pppoa_llc".
This is sometimes called "RFC 2364 LLC". - 7
- LLC encapsulated routed IP over AAL
In spd this is called "ip_over_aal5".
This is sometimes called "RFC 1483 Routed", "RFC 1577 Routed" or "RFC 2684 Routed". - 8
- Adaptive, much like PPPoE method.
In spd this is called "adaptive". - 9
- LLC encapsulated bridged 802.3 Ethernet over AAL5.
In spd this is called "bridged_over_aal5".
Sometimes this is called "RFC 1483 bridged" or "RFC 2684 bridged".
Standard rules
cFosSpeed ships with five traffic classes, called "highest", "higher", "high", "low" and "lowest". To assign traffic to these classes, we have combined individual rules into mega-rules.
If you remove the standard rules, you will most likely disable or damage the traffic-shaping operation of cFosSpeed. So, it's an excellent idea to leave them in place and just add your own rules below these rules!
Traffic classes
cFosSpeed has two built-in traffic classes: "default" and "drop". All traffic that isn't matched by anything else goes to "default". Its implicit priority is 0.
You can use "drop" to delete a packet and don't send it at all. This allows you to do your own little firewalling with it (only for outbound traffic). "Drop" has no priority.
Used to order classes, "priority" is entered as an integer. To avoid confusion, no two classes should be assigned the same priority value. Packets of a traffic class with higher priority are sent prior to packets belonging to a traffic class with lower priority.
"Priority" is usually a positive value for regular classes. However, you can specify "low prio" classes with a negative priority value. Packets in low prio classes are only sent out if there is no high and no default class traffic ready for transmission.
This concept is exactly the opposite of high prio class. With high prio classes, you can mark specific packets to be sent out in front of other data. With low prio classes, you can mark specific packets to be sent out after other data. Beware that specifying rules for low classes can easily lead to "starving" connections, because all other data would then take precedence.
In addition, all traffic classes can be assigned a speed setting. The speed setting determines up to how many bytes/second the class priority will remain in effect. Beyond that, packets are treated as being in the default class. That way, for instance, you could prioritize traffic, but only if it does not exceed, say, 1000 bytes/second. Once that speed is exceeded, the traffic would not be prioritized any more.
The speed settings can done in percent as well, where 100% denotes the total speed of the connection. Specifying "-speed 20%" and "-speed 20perc" means the same. Speed settings of low classes must have a priority value that is used in case the speed is exceeded. It looks like this: "-speed 20%,-10".
As an example take the setting "-prio 0 -speed 20%,-10". Traffic in this class is sent out with priority 0 (i.e., default) if it's slower than 20% of the maximum speed and with priority -10 otherwise.
DSCP configuration
Classes can have a DSCP value as well. If set, this value is set to all outgoing packets of that class. Specify "-dscp X" in the class line to set DSCP value of "X". DSCP values range from 0 to 63. By default, DSCP values are not set for any class. For more details see RFC 2474 (Differentiated Services, www.ietf.org/rfc/rfc2474.txt).
VLAN configuration
You can set VLAN Identifier (VID) and Priority Code Point (PCP) for traffic classes as well. To set VID, use "-vlan-id X" option for the traffic class, where "X" is the Identifier. VIDs range from 0 to 4095 (0xfff hex). To set PCP, use "-vlan-prio X", respectively, where X is the PCP. PCPs range from 0 to 7. If you set one of these, all outgoing packets will have VID and PCP set. By default, VLAN settings are not changed for the packets of any class. For more details see IEEE 802.1Q (e.g. on Wikipedia).
IP-range lists
In order to filter for huge amounts of IP-ranges, cFosSpeed has support for IP-range files like ipfilter.dat the same way IP-Blockers like Protowall and Peerguradian support them. All traffic to or from one of the listed addresses is blocked. We call those lists "iplists".
cFosSpeed supports these iplists through two filter expressions: -s-iplist and -d-iplist. They are already set by default in settings.ini. -s-iplist matches the source IP address against a given list, -d-iplist the destination IP address.
The -s-iplist and -d-iplist filter accept the iplist name as second parameter. The default name used in settings.ini is "ipfilter". In the [iplist] section in settings.ini or user.ini you must specify the iplist names with the corresponding IP block list files that contain the IP-ranges to be blocked. These block lists are not supplied with cFosSpeed.
The [iplist] section contains lines in the format "listname=filename". 'listname' is used to filter for the IP-addresses listed in 'filename'. You can have more than one list with different names and each list can be made up of more than one file. When compiling the lists, duplicate entries are removed and the whole list is sorted and optimized. You can put this section in user.ini, so it will not be overwritten with the next cFosSpeed update.
An example excerpt from settings.ini:
filter=-tx -d-iplist ipfilter -c drop filter=-rx -s-iplist ipfilter -c drop [iplist] ipfilter=c:\text\ipfilter.dat ipfilter=c:\text\my.dat
This will read both files and make them available as iplist named 'ipfilter'. This iplist is used by default to filter packets to the drop queue, i.e. to discard them. However, this rule is not active by default, since no IP block list file is set up.
Currently two IP-range file-formats are supported. This is the Emule format:
from-address - to-address [, rest-ignored...]Example:
0.0.0.1 - 3.255.255.255 , blablaAnd this is the Protowall/Peerguardian format:
ignored-text:from-address - to-addressExample:
blabla:0.0.0.1 - 3.255.255.255
The block lists can be quite big and consume a lot of memory. Each line with an IP-range needs 8 bytes. We worked with lists that needed 2mb of memory. The process of reloading them will, for a short time, allocate three times as much.
Since the lists are so big, they have to be read into memory from disk and compiled. This can take some short time, so it is only done when cFosSpeed is loaded or on demand. To re-load the block lists on demand use "spd reload -iplist".
Blocked packets will be dumped to text file FWLOG.TXT like all other firewalled packets. You can switch off the dumping by setting "spd gset fwlog 0".
RX-priorisation
Classes can have weights assigned for rx-priorisation. The concept is like this:
Each class (highest, higher, high, default, low, lowest) has a weight assigned. Furthermore, all TCP connections are mapped to a certain class (this only applies for bulk data; e.g. ACKs are always sent out in the higher class; see below for how the class mapping is done), according to filter rules. The class weight is used when TCP windows for rx-shaping are computed. A TCP connection with weight 100 gets a window that is about 4 times bigger than a connection with weight 25. This should usually translate into more speed on that connection, but not necessarily (e.g. the sending server might not be fast enough).
The pre-set weights are:
class highest -weight 400 class higher -weight 400 class high -weight 400 class default -weight 100 class low -weight 25 class lowest -weight 6
I.e. regular browser downloads (class default) should get about 16 times the speed than Torrents (class lowest).
The weighting needs some time (some seconds) to be through, so a newly created higher-than-average TCP connection needs these seconds to come to full speed.
How does cFosSpeed know which TCP connection has which class, since the filters assign classes on a packet-by-packet basis? Well, there are filter expressions that are constant for all packets that belong to a certain connection. The expression might be true or false, but it doesn't change from one packet to the next. You can see which filter expressions have this criterium by using "spd filter":
rt- -highest -c highest rt- -higher -c higher rt- -high -c high rt- -l7-prot @higherprots -c higher rtc -l7-prot @highprots -c high rtc -l7-prot @lowprots -c low rtc -l7-prot @lowestprots -c lowest rt- -prog @higherprogs -c higher rtc -prog @highprogs -c high rt- -prog @lowprogs -c low rtc -prog @lowestprogs -c lowest rt- -low -c low
The first column (with the "rtc") shows this: 'r' means the filter is active when receiving packets, 't' means the same for transmitting packets. 'c' means that it is constant and thus 'c' is set for the -l7-prot and -prog rules, since the l7-protocol and program name are saved on a per-connection basis. The -high etc. filters are packet specific and thus have no 'c' set.
Now what if cFosSpeed is wrong about the constantness of a filter expression? For example you could have DSCP values assigned to certain connections from another machine, but the -dscp rule is a per-packet rule, not a per-connection rule. To force cFosSpeed to set the class even on account of such a filter expression, use the -force-set-class option. By using this, the filter expression will be flagged 'c' and thus considered constant over all packets of that conenction.
Standard configuration
cFosSpeed comes preconfigured with five different traffic classes (in addition to the two built-in classes):
Creating your own rules
If you want to assign a class to your own prioritized traffic, use "high". It's probably best not to use the other two classes, as this may interfere with overall traffic-shaping performance. You may even add a class of your own, but don't use a priority of 90 or more for the same reason mentioned above.
Keep in mind that what the whole prioritization system basically does is reorder packets for transmission. Thus, prioritizing more packets will leave fewer packets "normal". Taken to the extreme, this means that priotizing every single packet indiscriminately would soon slow traffic on the fast lane to little more than stop and go.
The spd utility (see below) and the trace.txt file can be used to show class-usage statistics. As a general rule of thumb, I'd advise you prioritize no more than 10% or 20% of your traffic.
The spd utility
The cFosSpeed installation directory contains a small file called spd.exe for communicating with cFosSpeed. It lets you handle commands and will display results for you.
An easy way to use the spd tool is to click on Start - Programs - cFosSpeed - Open Console. This will bring up a regular command prompt with the cFosSpeed directory as the current one.
Another way would be to copy it to some directory in your PATH.
"spd help" provides a list of commands.
"spd ver" shows cFosSpeed version information.
Changing expressions and classes
"spd class" lists all traffic classes. It usually
looks like this:
class highest -prio 100 -weight 400 class higher -prio 90 -weight 400 class high -prio 80 -weight 400 class default -weight 100 class low -prio 0 -speed 25%,-10 -weight 25 class lowest -prio 0 -speed 25%,-30 -weight 6 class drop
If you want to add a class, use "spd class <name> -prio <prio>", where <name> is the class name and <prio> the assigned priority.
If you want to delete a class, use "spd class <name> -D". Classes can only be deleted if there are no expressions referring to them.
You can later change the priority of an already existing class <name> by using "spd class <name> -prio <prio>". However, you cannot change a low into a high class or vice-versa.
Likewise, you can change the speed of a class after it's been created. Just use "spd class <name> -speed <speed>" on an already existing <name>, where <speed> can be any positive number or "inf" for no speed limit.
You can get a list of the active filters by using the "spd filter" command. This will usually read something like this:
0 -highest -c highest 1 -higher -c higher 2 -high -c high 3 -prog @user.ini/highprogs -c high 4 -prog @highprogs -c high 5 -low -c low 6 -prog @user.ini/lowprogs -c low 7 -prog @lowprogs -c low 8 -prog @user.ini/lowestprogs -c lowest 9 -prog @lowestprogs -c lowest
New filter expressions can be appended to the bottom of the expression list by the "spd filter -A <filter> -c <class>" command, where <filter> is a set of filter rules and <class> is the target traffic class.
In the same way, you can use "spd filter -I <pos> ..." to insert a filter at a specific position into the filter list.
"spd filter -R <pos> ..." replaces the filter at position <pos> with the new filter.
"spd filter -M <old> <new>" moves a filter from its old position <old> to a new position <new>.
Finally, "spd filter -D <pos>" deletes a filter at position <pos>.
If you want to review your traffic-class usage, type "spd cstat" to get corresponding statistics. This is an example of what it looked like after a long time transferring:
shaping is currently enabled; txspeed = 139907, max_queue_size = 419,721 class highest -prio 100 -weight 400 sent 320,292 ( 2%) packets 8,968,176 ( 0%) bytes in queue 0 packets 0 bytes class higher -prio 90 -weight 400 sent 1,045,165 ( 8%) packets 42,809,356 ( 0%) bytes in queue 0 packets 0 bytes class high -prio 80 -weight 400 sent 411,963 ( 3%) packets 66,261,691 ( 0%) bytes in queue 0 packets 0 bytes class default -weight 100 sent 103,663 ( 0%) packets 15,722,812 ( 0%) bytes in queue 0 packets 0 bytes class low -prio 0 -speed 25%,-10 -weight 25 sent 4,670 ( 0%) packets 5,979,376 ( 0%) bytes in queue 0 packets 0 bytes class lowest -prio 0 -speed 25%,-30 -weight 6 sent 9,828,143 ( 83%) packets 10,913,999,530 ( 98%) bytes in queue 0 packets 0 bytes class drop dropped 0 packets 0 bytes queue overflow 0 packets 0 bytes
Filter expressions and classes can be modified while cFosSpeed is up and running online. If you want to save the changes you made, use "spd save" with either -class, -filter or -all to specify what to save.
You can change settings.ini from the outside with an editor as well. But you have to reload the new settings after you saved the new version of settings.ini by typing "spd reload". This will, however, only reload the filter settings, not the classes.
Managing program names:
To manage lists of programs that are to be filtered with -tcp-prog, -udp-prog or -prog there are three commands:
More useful commands:
With the "spd netstat" command, you can review statistics of the total traffic transmitted over your line. After the long time mentioned above, our sample stats looked as follows:
IP statistics sent rcvd bytes sent bytes rcvd Good packets 11,714,403 8,245,216 11,053,999,872 1,874,597,769 Fragments 5,267 4,608 5,781,578 4,195,207 Fragment timeouts 5,191 4,532 Fragments ignored 72 76 47,732 42,236 Protocol 2 (IGMP) 13 0 520 0 ARP statistics sent rcvd bytes sent bytes rcvd Good packets 783 130,384 21,924 5,997,484 ICMP statistics sent rcvd bytes sent bytes rcvd Good packets 320,702 341,119 9,027,507 19,482,227 Bad packets 0 1,085 0 114,283 UDP statistics sent rcvd bytes sent bytes rcvd Good packets 1,479,668 1,256,672 146,482,897 158,899,222 TCP statistics sent rcvd bytes sent bytes rcvd Good segments 9,905,831 6,638,246 10,892,171,744 1,691,413,796 Checksum errors 0 97 0 9,394 Segments w/o connection 1,961 826 223,937 36,904 Invalid RST segments 3 7 ACKs for unset data 0 2 Segments after reset 765 562 78,108 299,641 Filtered resents 193 233,461 Used sequence space 10,304,070,182 1,409,658,307 Resent segments 184,715 23,005 196,810,498 14,087,200 Reordered segments 13 200,175 556 80,270,918 Total sessions 66,765 Active sessions 4 Orderly releases 60,222 Abortive releases 6,091 Timeouted sessions 448 Failed connection attempts 15,905 2,396 Peak sessions 147 Peak half-open sessions 121 RTP statistics sent rcvd bytes sent bytes rcvd RTP Packets 0 0 0 0 RTCP Packets 347 331 9,032 9,552
It's really a lot like the Windows NETSTAT command, except it does only count packets transmitted on the cFosSpeed connection rather than all packets in the system and in some respects it's much more detailed.
The "spd cperf" command will switch on or off class traffic dumping. By setting "spd cperf on" cFosSpeed will dump about once per second how many bytes were sent in what priority class. This can help in testing filter rules or finding performance problems.
"spd fstat" command displays which filters matched how often. Use it to check if your filters are working. "spd fstat -clear" clears the stats.
Connection Technology setting
cFosSpeed tries to auto-detect which technology you use to access the Internet. Sometimes it guesses wrong or the technology used it too esoteric. Here is a list of currently suppoted values:
You can check the value by issuing a "spd set method" command or change it by using "spd set method X", where X is the new value.
TCP MSS handling
cFosSpeed manages your TCP MSS ("MSS clamping") (i.e., the MTU for TCP packets) automatically. The MSS values chosen are chosen so data transfer rates are maximized and ping times are minimized.
But if you want cFosSpeed to leave the MSS alone, you can enter "spd gset handle_mss 0" to instruct it so. Add a "-save" to have the setting saved in cfosspeed.ini.
Switching off MSS handling is not recommended.
That's it.
Have fun making up your own traffic shaping rules!