* Overview [1]
* Multiple Interfaces [2]
* Flexible configuration [3]
* Control Domains [4]
* Control Token [5]
* Configuration [6]
* MW frottle patch [7]
* Change log [8]
* openwrt version [9]
* README for the patch [10]
* Netfilter interaction [11]
* Ongoing discussion [12]
OVERVIEW
This discussion is driving changes we are making to the frottle
application. There have been three major things we wanted to address:
* Support for multiple interfaces on a machine
* Expose magic cookies in application as configuration parameters
* Introduce the concept of control domains
This has led to a number of other enhancements, the most significant
being the desire to pass a control token from master to master. This
was considered necessary to utilize frottle effectively in a mesh type
network.
MULTIPLE INTERFACES
Nodes that form part of a routing backbone have multiple interfaces.
As there is only one QUEUE target we needed to be able to define
additional interfaces and split the incoming traffic into the
appropriate set of queues for the outgoing interface.
A Node may be the master of one domain on one interface and a client
in a second domain via a second interface.
FLEXIBLE CONFIGURATION
The intial thought was we would be running multiple copies of frottle
ona multi-interface machine. We wanted to have a way to simplify the
configuration. This led to adding a number of command line args, pre-
and post- script callouts and the externalization of some hard coded
parameters.
CONTROL DOMAINS
It became clear as soon as we started looking at multiple interfaces
that we needed to support the concept of a control domain. These were
added and clients and masters specified in terms of the domain they
belong to.
CONTROL TOKEN
This is new work to better support the use of frottle in a mesh
environment. The problem faced here is that a mesh uses the same
frequency and frottle sucks at controlling the traffic from a node
that is not directly connected. A multi master approach ( as used in a
routed infrastructure ) still has problems due to the single frequency
used. We are now looking at using a co-master approach where masters
pass control to the next master in the chain. The chain is a ring that
supports splitting and healing.
CONFIGURATION
FROTTLE CONFIG FILE
DanFlett [13]: Here's how I'd like to be able configure a
multi-interface version of Frottle...
PROPOSED FROTTLE.CONF
daemon 1 verbose 1 logfile /var/log/frottle.log clientstatsfile
/var/www/html/frottle/client.html masterinfofile
/var/www/html/frottle/master.html #MODE-CLIENT INTERFACE MASTER IP
PRIORITY PORTS PORT QUEUESIZE client wlan0 10.10.144.49 22,53 999 100
client eth0 10.10.255.1 22,53,5001 - 100 client eth2 10.10.129.1 -
1001
# CLIENTMODE #MODE-MASTER INTERFACE (SELF/CLIENT/NONE) TIMEOUT
POLLPARAMS master eth1 self 100 60000,10,6000,7,5000,5,4000 master
wlan1 - 200
You get the idea - leaving a paramater blank (if there are no
parameters to be specified after it) or specifying '-' (if there are
parameters to be specified after it) for a parameter sets it to
default - where appropriate. This is similar to the way Shorewall [14]
sets out its config files [15].
MW FROTTLE PATCH
OK, here it is, everything you asked for and a little bit more. The
major change from above is the introduction of domains. Define the
domains and associate the master / client instance to a domain.
frottle-mw-patch.tar [16]
frottle_0.2.1-MwPre0.5_mipsel.ipk [17]
This is beta code, I have tested the patch on Minitar MNWAPB (RTL8181
mips ) and openwrt(BROADCOM mipsel).
CHANGE LOG
_MwPre0.3_ is now built with iptables 1.3.1. and staticly linked (no
need for libpthread.o)
_MwPre0.4_ adds manual override of RF Rate setting in client for
hosts that do not support /proc/net/wireless
_MwPre0.5_ adds configuration of rate bands for queues ( used in
conjunction with pollparams ) and supports calling an external command
to get rate
_MwPre0.6_ adds the priority client option ( allowing the
specification of a bigger slice for a know high priority machine- such
as an internet gateway or a trunk ) and adds multiple sets of Queues
to finish of the multi-domain work.
_MwPre0.7_ has a primitive token passing mechanism for passing off
control from master to master. Masters and Domains need to be defined
in the .conf file.
OPENWRT VERSION
The openwrt kernel does not include the ip_queue code so it needs to
be loaded as a module.
The ipkg for the correct module is/was here: iptables_extra [18]
Install the ipkg then:
insmod ip_queue.o lsmod
and away you go....
README FOR THE PATCH
This patch contains a number of small changes to frottle 0.2.1
To install:
apply patch from inside the frottle directory patch -p1 <
path-to-patch/frottle-0.2.1-mwPre0.1.diff
The changes were done in order to make configuring frottle easier in
a
multi-interface environment.
1. New command line arguments
frottle master | client [19] [20] [21]
--mode master | client This argument is used to select an alternative
configuration file: master /etc/frottle-master.conf client
/etc/fottle-client.conf Mode parameters still need to be set in the
configuration file. --interface This argument allows the interface
specified in the configuration file to be overridden.
--port This argument allows the Master port specified in the
configuration file to be overriden. Care should be used with this
argument as only a correct combination of Master IP addr and Master
port will allow a client to connect to a master instance.
2. Support for re-named binary.
If the frottle binary is launched using the name frottlemaster
either renamed, hard or soft linked then it will default to -mode
master
3. New configuration file options
#pidFile
#pidfile /var/run/frottle.pid
If this option is defined the process ID will be written to the file
specified.
No checking for multiple instance is done at this stage. If the file
already
exists then the pid will be added to the file. On shutdown the file
is unlinked
(this will be a problem in the case of multiple instances).
pre and post scripts are supported for Master and Client
configurations.
The specified script will be called with the following arguments:
scriptname interface masterport
#Master pre-script
#masterprescript /usr/local/frottle_master_pre.sh
#Client pre-script
#clientprescript /usr/local/frottle_client_pre.sh
#Master post-script
#masterpostscript /usr/local/frottle_master_post.sh
#Client post-script
#clientpostscript /usr/local/frottle_client_post.sh
#Client re-register timeout
#clientreregister 10
The client retry time was hard coded. this is now configurable. If
the client
does not hear from the master after this time it assumes it has been
dropped
and will try to re-connect. 10 was the hard coded default, may be a
little high.
#Client timeout
#clienttimeout 60
The client will timeout if nothing is hear from the master after this
time.
It will fall out of the frottle configuration. This was hard coded
and
is now configurable.
#Client link speed
#clientlink 0
In some cases the IOCTL that is used to return the link speed will
fail in
the client. This will leave the client at the fastest linkspeed
default. This
may not be desirable. Setting clientlink to non zero ( set to the
link rate )
it will override the internal default. Use this to reduce the TX
window in
clients on a slow link to prevent them hogging the available time.
4. Bug fixes
Bandwidth allocation was testing for link speed >=5 else ==2 else
other.
This was changed to >=5 else >=2 else other.
Errors in the management of the client concetion state meant that
once a
conncetion was timed out it would repeatedly go through flushing the
queued
packets when this was not necessary.
5. Known Issues
Need some more work on the thread join for multiple interface
support. This is
only on shutdown and sems to work Ok.
Config file parsing logic has a error where it is looking for blank
lines.
This is cosmetic but should be fixed at some stage.
The link speed setting from the wireless interface divides the value
returned
from the IOCTL cal by 1000000. It may be it should be divided by
10,000,000.
As it stands if the value returned is 54,000,000 then it is going to
be 54.
In the code the time slice is allocated according to >=5, >=2,
Links:
------
[1] http://melbournewireless.org.au/#overview
[2] http://melbournewireless.org.au/#multiple_interfaces
[3] http://melbournewireless.org.au/#flexible_configuration
[4] http://melbournewireless.org.au/#control_domains
[5] http://melbournewireless.org.au/#control_token
[6] http://melbournewireless.org.au/#configuration
[7] http://melbournewireless.org.au/#mw_frottle_patch
[8] http://melbournewireless.org.au/#change_log
[9] http://melbournewireless.org.au/#openwrt_version
[10] http://melbournewireless.org.au/#readme_for_the_patch
[11] http://melbournewireless.org.au/#netfilter_interaction
[12] http://melbournewireless.org.au/#ongoing_discussion
[13] http://melbournewireless.org.au/?DanFlett
[14] http://shorewall.sourceforge.net/
[15] http://shorewall.sourceforge.net/Documentation.htm#Rules
[16] http://melbournewireless.org.au/files/Misc/frottle-mw-patch.tar
[17]
http://melbournewireless.org.au/files/Misc/frottle_0.2.1-MwPre0.5_mipsel.ipk
[18]
http://bcan.burngreave.net/bcanopenwrt/packages/kmod-iptables-extra_2.4.30-1_mipsel.ipk
[19] http://melbournewireless.org.au/?--mode
[20] http://melbournewireless.org.au/?--interface
[21] http://melbournewireless.org.au/?--port
[22]
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.4
[23]
http://www.google.com/search?num=100&hl=en&safe=off&q=%22libipq%22&btnG=Search&meta=lr%3Dlang_en
[24]
http://www.google.com/search?num=100&hl=en&safe=off&q=%22libipq%22+address&btnG=Search&meta=lr%3Dlang_en
[25] http://www.crhc.uiuc.edu/~grier/projects/libipq.html
[26] http://www.superhac.com/archives/01-01-2005_01-31-2005.html
[27] http://melbournewireless.org.au/?IFNAMSIZ
[28] http://melbournewireless.org.au/?IFNAMSIZ
[29] http://melbournewireless.org.au/?8
[30] http://melbournewireless.org.au/?0
[31] http://melbournewireless.org.au/?MelbWirelessRouterProject
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]
Node Statistics | |
---|---|
building | 132 |
gathering | 192 |
interested | 515 |
operational | 242 |
testing | 216 |