-# ALLOCATION OF PIPES AND RULES
-# pipes are always allocated in pairs
-# rules are either individual or in groups of size NUM_RULES (e.g. 4)
-# and are allocated in two different parts of the rule namespace
-# (e.g. blocks from 10000 to 49999 and individuals from 50000 to 59999)
-# Internally allocator uses the base number for each item, e.g.
-# rule 10000..49999 -> rule_base=1..10000
-# rule 50000..59999 -> rule_base=10001..20000
-# pipe 10000..59999 -> pipe_base=1..25000
-# a bit of math lets us compute the correct numbers.
-# For CLIENT, SERVER, SERVICE the database contains entries as
-# XID TYPE arg rule_base pipe_base
-# For blocks the entries are
-# XID RULE - rule_base -
-# XID PIPE - - pipe_base
-# When a rule or pipe is referenced we first check that the owner owns it.
-# more details below.
+#
+# initialize the firewall with PlanetLab default rules
+ipfw_init() {
+ ${IPFW} -q delete $S
+ ${IPFW} -q delete $D
+ ${IPFW} add $S skipto tablearg lookup jail $SLICE_TABLE
+ ${IPFW} add $D allow all from any to any
+}
+
+#
+# if present, call a hook function
+# Arguments are:
+# slice_id type port rule_base pipe_base timeout
+hook_call() {
+ if [ -n "${HOOK}" -a -x "${HOOK}" ]; then
+ debug "Calling the hook function."
+ ${HOOK} ${SLICE_ID} "$*" &
+ fi
+}
+
+do_help() {
+ cat << EOF
+Usage:
+ ./neconfig [SERVER|CLIENT|SERVICE] port [-t timeout] \
+ PIPE_IN <pipe in configuration> PIPE_OUT <pipe out configuration>
+ ./netconfig show [rules|pipes]
+ ./netconfig delete [SERVER|CLIENT|SERVICE] port
+ ./netconfig refresh [-t timeout] [SERVER|CLIENT|SERVICE] port
+
+We assume three type of connections
+ SERVER we know the local port P, and do the
+ bind/listen/accept on the local socket.
+ pipe_in in dst-port P
+ pipe_out out src-port P
+
+ CLIENT we know the remote port P, and do a connect to it
+ (src and dst are swapped wrt the previous case)
+ pipe_in in src-port P
+ pipe_out out dst-port P
+
+ SERVICE we run a server on local port P, and also connect
+ from local clients to remote servers on port P.
+ pipe_in in { dst-port P or src-port P }
+ pipe_out out { src-port P or dst-port P }
+
+ On a given port a user can have one CLIENT and/or one SERVER
+ configuration or one SERVICE configuration.
+ When a SERVICE configuration is installed any existing CLIENT
+ and SERVER configuration on the same port are removed.
+ When a CLIENT or SERVER configuration is installed any existing
+ SERVICE configuration on the same port is removed.
+
+The pipe configuration, both for the upstream and downstream link,
+follow the dummynet syntax. A quick and not exaustive example
+of the parameters that can be used to configure the delay,
+the bandwidth and the packet loss rate for a link follow:
+
+ PIPE_IN|PIPE_OUT delay 100ms bw 1Mbit/s plr 0.1
+
+The full documentation is on the manpage[1].
+
+The timeout value follow the linux 'date' command format[2]
+and can be specified as follow:
+ 1week
+ 2hours
+ 3days
+
+--- References:
+[1] http://www.freebsd.org/cgi/man.cgi?query=ipfw
+[2] http://linuxmanpages.com/man1/date.1.php
+EOF
+}
+
+# ALLOCATION OF RULES AND PIPES
+# The ruleset is composed by different sections, as follow:
+# - a first set of rules is reserved and is configurable by
+# the root context only;
+# - the skipto rule (S), used to optimize the slice rule search;
+# - a second block of reserved rules;
+# - a default (D) rule for the generic configuration;
+# - the slice reserved rules, a block of M rules for each slice;
+# - the firewall default rule.
+#
+# To summarize:
+# 1...S-1 first block of reserved rules
+# S skipto tablearg lookup jail 1
+# S+1..D-1 ... second block of reserved rules
+# D allow ip from any to any
+#
+# RULE_BASE <block of M entries for first user>
+# RULE_BASE+M <block of M entry for second user ...>
+# ...
+#
+# Out of 64k rules, we allocate a block of M=50 consecutive
+# rules to each slice using emulation. Within this block,
+# each configuration uses one rule number and two pipes.
+#
+# Pipes are allocated starting from PIPE_BASE, a couple
+# of pipes for each configuration.
+#
+# DATABASE FORMAT
+# The database is stored on a file, and contains
+# one line per record with this general structure
+# XID TYPE arg1 arg2 ...
+# whitespace separates the fields. arg1, arg2, ...
+# have different meaning depending on the type.
+#
+# In the database we have the following records:
+# - one entry for each slice that has active emulation entries.
+# For each of these slices we reserve a block of M ipfw rules
+# starting at some RULE_BASE rule number.
+# The database entry for this info has the form
+# XID BLOCK block_index
+# where blocks are numbered sequentially from 1.
+# The actual ipfw rule numbers for the block are the M rules starting at:
+# IPFW_RULE_MIN + (M-1)*(block_number)
+#
+# - one entry for each predefined config (CLIENT, SERVER, SERVICE).
+# The database entry for this info has the form
+# XID {CLIENT|SERVER|SERVICE} arg ipfw_rule pipe_index
+# ipfw_rule is the unique ipfw rule number used for this configuration
+# (it must be within the block of M rule indexes allocated to the slice)
+# pipe_index is the index of the couple of pipes used for the
+# configuration. pipe_index starts from 1. The actual pipes are
+# ipfw_pipein = IPFW_PIPE_MIN + 2*(pipe_index-1)
+# ipfw_pipeout = ipfw_pipein + 1
+#