When a command is called, it needs to know some information about the context of the call in the rules file. This is done using a few global variables like:

• $iface
• $profile (used internally by addcode)
• $state
• $type
• $IP
• …. any other needed?

Initially all are empty.

The changes on the state and types are described in the following diagram using the this syntax:

• * means any $state, any $type.
• foo(*) means $state = foo, but any $type
• foo=bar means foo is set to “bar”
• $n means the n-er argument

This diagram is on a very early stage, we have to see how each command affects the global variables. Please, We need your opinions to polish it:

  * -> interface -> state=new, type=undefined, IP=, iface=$1, profile=$2
  new(undefined) -> ip -> state=normal, type=static, IP=$1
  new(*) -> ip -> state=normal, IP=$1

When we addcode we need to decide when do we want this code to run. The life of an interface pass by different states and the first argument of addcode determines that.

When snet will perform an action to goes to the coded added to a given state (or chain) and then execute everything in (level, $sublevel, $timestamp) order. and then pass to the next state an does the same. So….. we have to define this states considering what do we want to up/down/reload without affecting other parts of the setup, and without dropping the interface completely.

Currently I see four “subsystems”, each with an up and down state. Here you can see the subsystems and the suggested name for the state.

• interface (init, finish)
• routing (up, down)
• firewall (fwup, fwdown)
• QoS (qosup, qosdown)

which leads for each interface to something like:

init -> up --> fwup --> fwdown ----> down -> finish
           `-> qosup -> qosdown --'

Suggestions welcomed.