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 arrived before high-priority 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 the 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. Accordingly, for this rule to be true, the packet must have IP protocol TCP and the TCP source port must be 1234.
Then, there is a second rule, 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 (which doesn’t exist by default).
If neither of the two rules apply to the packet (which should happen fairly often), it is 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 exists). 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 a rule with a non-matching implicit assumtion is false even if it is negated (by using ‘!’).
That is, a !-tcp-length 0 rule matches TCP packets of any length other than zero, but does 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”. There must be no space around the comma.
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 both transmit and receive. By using this rule you specify that a filter is only to 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 analogously. - -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
- 0x86dd
- IP, Internet Protocol version 6
- -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
- 0x57
- IPv6, Internet Protocol version 6
- 0x8021
- Internet Protocol Control Protocol
- 0x8057
- IPv6 Control Protocol
- 0xc021
- Link Control Protocol
- -ipv4
- IP version 4. True if the packet is IPv4 and basically well-formed.
- -ipv6
- IP version 6. True if the packet is IPv6 and basically well-formed.
- -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 v4 header can be found in RFC 791 (Internet Protocol), www.ietf.org/rfc/rfc0791.txt and details on the IPv6 header can be found in RFC 2460 (Internet Protocol, Version 6) www.ietf.org/rfc/rfc2460.txt.
IP header filter rules apply only to IP packets with a correct header and checksum (IPv4 only, IPv6 has no header 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
or 2001:0db8:0000:0000:0000:ff00:0042:8329
or [2001:db8::ff00:42:8329]
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
or 2001:0db8::/64
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 (IPv4) resp. 128-bit (IPv6) number. Thus, for IPv4 “/24” is 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
or 2001:0db8::/64,[fe80::1],8.9.0.0/16
You can make a list of any of the above used notations and mix IPv4 and IPv6. 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.
- -l address-list
- Local IP address, where “address-list” has the same format as explained for the -s filter.
The local address is the source address of a sent packet and the destination address of a received packet. - -r address-list
- Remote IP address, where “address-list” has the same format as explained for the -s filter.
The remote address is the destination address of a sent packet and the source address of a received packet. - -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
- HOPOPT
- protocol number 0
- IGMP
- protocol number 2
- TCP
- protocol number 6
- UDP
- protocol number 17
- IPV6
- protocol number 41
- IPV6-ROUTE
- protocol number 43
- IPV6-FRAG
- protocol number 44
- GRE
- protocol number 47
- ESP
- protocol number 50
- AH
- protocol number 51
- ICMPv6
- protocol number 58
- IPV6-NONXT
- protocol number 59
- IPV6-OPTS
- protocol number 60
- MOBILITY
- protocol number 135
- -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” bit is set.
- -df
- “Don’t Fragment” bit in IP header set (IPv4 only, there is no such bit under IPv6).
- -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. Under IPv6 this rule refers to the “traffic class” field of the header. - -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, including the header.
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.
For IPv6, this does not include the HOPOPT, ROUTE, DESTOPTS, MOBILITY and FRAG extension headers. They are not considered part of the “data”.
You can also specify a range for “value”. - -ihl value
- Length of the IP v4 header, with values anywhere from 20 to 60 (IPv4 only). 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.
- -l-mynet
- The local address is in your subnet.
- -r-mynet
- The remote address is in your subnet.
- -s-bcast
- The source address is the subnet directed broadcast address (IPv4 only, there is no such concept under IPv6). 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.
- -l-bcast
- The local address is the subnet directed broadcast address. See -s-bcast for more info.
- -r-bcast
- The remote 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”.
- -l-iplist list
- The local address is listed in the iplist named ‘list’. For more on iplist’s see “IP-range lists”.
- -r-iplist list
- The remote 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 (IPv4 only). 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 (v4 or v6) header, since UDP needs IP for transmission.
UDP header filter rules apply only to packets with a correct IP header, protocol set to UDP, 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 including the UDP header as mentioned in the UDP header.
Since the UDP header is as well counted 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 (v4 or v6) header, since TCP needs IP for transmission.
TCP header filter rules apply only to packets with a correct IP header, and protocol set to TCP. 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 has 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 the rule matches.
- -tcp-flags ALL SYN
- means: if only the SYN bit is set and all others are zero, then the rule is 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
- 8
- At least one side has sent a FIN that has been ACKed: connection half-closed
- -tcp-session-dadr value
- There is a TCP connection in 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 from local, “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!). To 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 for IPv4 header can be found in RFC 792 (Internet Control Message Protocol, www.ietf.org/rfc/rfc0792.txt) and details on the ICMPv6 header can be found in RFC 4443 (Internet Control Message Protocol (ICMPv6) for IPv6, www.ietf.org/rfc/rfc4443.txt). Note that each ICMP header is prefixed by an IP (v4 or v6) header, since ICMP needs IP for transmission.
ICMP header filter rules apply only to packets with a correct IP header, protocol set to ICMP or ICMPv6, 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 v4 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. - -icmpv6-type type – or – -icmpv6-type type/code
- Check for ICMPv6 type and code (if specified).
The syntax and semantics for this rule are like -icmp-type. - -icmp-length value
- Length of the ICMP data portion, including the ICMP header. This is the IP v4 or v6 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 apply if the packet has a VLAN header at all.
- -is-vlan
- Matches if a packet has 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.
Standard rules
cFosSpeed ships with five traffic classes, called “highest”, “higher”, “high”, “low” and “lowest”. To assign traffic to these classes, we have combined sensible 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!
- -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.