Frottle uses the iptables QUEUE target to delay outgoing traffic. The
QUEUE target was designed to allow userspace applications, like
Frottle, to inspect and control network traffic.
The QUEUE target is explained here:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.4
[1]
Here is the relevant exerpt:
QUEUE is a special target, which queues the packet for userspace
processing. For this to be useful, two further components are
required:
* a "queue handler", which deals with the actual mechanics of passing
packets between the kernel and userspace; and
* a userspace application to receive, possibly manipulate, and issue
verdicts on packets.
The standard queue handler for IPv4 iptables is the ip_queue module,
which is distributed with the kernel and marked as experimental.
The following is a quick example of how to use iptables to queue
packets for userspace processing:
# modprobe iptable_filter # modprobe ip_queue # iptables -A OUTPUT
-p icmp -j QUEUE
With this rule, locally generated outgoing ICMP packets (as created
with, say, ping) are passed to the ip_queue module, which then
attempts to deliver the packets to a userspace application. If no
userspace application is waiting, the packets are dropped.
To write a userspace application, use the libipq API. This is
distributed with iptables. Example code may be found in the testsuite
tools (e.g. redirect.c) in CVS.
The status of ip_queue may be checked via:
/proc/net/ip_queue
The maximum length of the queue (i.e. the number packets delivered to
userspace with no verdict issued back) may be controlled via:
/proc/sys/net/ipv4/ip_queue_maxlen
The default value for the maximum queue length is 1024. Once this
limit is reached, new packets will be dropped until the length of the
queue falls below the limit again. Nice protocols such as TCP
interpret dropped packets as congestion, and will hopefully back off
when the queue fills up. However, it may take some experimenting to
determine an ideal maximum queue length for a given situation if the
default value is too small.
Presently, Frottle is only capable of acting on one network interface
at a time on the host on which it is running. To be part of a truly
scalable network, it would be desireable for Frottle to act on any and
all of a hosts' wireless interfaces. For instance, a host may have one
interface which is acting as a Access Point, and two more interfaces
making client connections to two remote APs. It would be desireable
for Frottle to be able to simultaneously act as a Master on the AP
interface and as a Client on each of the client interfaces.
As mentioned in the exeprt above, the QUEUE target requires:
_a userspace application to receive, possibly manipulate, and issue
verdicts on packets._
Frottle does this, but currently it is able to manipulate the
transmit order of packets in the QUEUE based on port number only. This
is the controlled by the "HIPORT" paramater in the Frottle config
file.
For Frottle to be able to act on different interfaces, it needs to be
able to manipulate packets in the QUEUE based on their destination IP
or Ethernet MAC address also. Packets being sent to one interface will
be within a certain IP address range, packets being sent to another
interface will be from a different IP address range.
Links:
------
[1]
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.4
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]
Node Statistics | |
---|---|
building | 132 |
gathering | 191 |
interested | 520 |
operational | 232 |
testing | 212 |