In order to make netfilter happy, we have to create a fake routing table
entry. Unfortunately, the kernel really doesn't like this when it actually
needs to make use of it. This code now removes the link between the packet
and the fake routing entry when the packet is being sent to a local port.
Otherwise it won't be found when run as non-root because such users
typically don't have /usr/sbin in $PATH. (We use tcpdump in a fashion
that doesn't require root privilege.)
Fail-open mode is entered or left in a secchan "periodic" callback, which
may not be called immediately after the connection to the controller
actually comes up. This can cause the fail-open local-packet CB to
locally handle messages from the datapath and drop them, causing the
controller to think that it's being ignore and drop the connection.
Thanks to Dan for raising the issue.
Before, we tried to use the port configuration bits to implement STP; e.g.
if a port was in LISTEN state we turned off sending and receiving frame
other than BPDUs. Unfortunately this interacts very badly with in-band
control: when the switch connects to the controller, it can be connected
to the controller over a port that is not in FORWARD, and so then the
controller disabled that port, and the connection eventually dropped when
an echo request/reply failed to get through.
Now, we implement STP by querying the flows on the switch and killing
off the ones that STP does not allow. This works much better because,
although we still kill off the in-band control connection, the in-band
hook in secchan is then able to resurrect it.
--no-stp is still the default since this has not been tested very much.
Logging DHCP messages sent or received with priority DBG made it hard
to see what was happening. So log them at priority WARN, but also make
them less verbose at that level since seeing the whole message is not
too useful most of the time.
The "min_timeout" variable maintained by the DHCP client is measured
in seconds from the time the state was entered, but dhclient_wait()
was interpreting it as seconds from now. This made the DHCP client wait
much longer than necessary in some cases.
Change e10dfcf35, "rconn: Be pickier about what constitutes a successful
connection," caused rconn to consider the connection to have failed even
when we are actually connected until one of several message types was
received. Unfortunately, that meant that "fail open" would intercept and
discard all messages sent by the controller until one of those messages
was received. Thus, the controller would never receive a reply to its
feature_request, assume that the connection was busted, and disconnect.
This happened forever, of course.
Fixes bug #242.
Thanks to Reid for reporting this and Dan for help in diagnosis.
To enable SNAT, run configure with the "--enable-snat" flag. This has
only been tested with the 2.6.23 kernel...more diverse testing will follow.
Documentation and a cleaner build setup will also be in a future check-in.
When secchan is configured to "fail open" after failing to connect to
a controller for a period of time, it needs a heuristic for what
constitutes a successful connection. Until now, that heuristic was
simply that when it received an OpenFlow message from the controller
(any OpenFlow message), it considered the connection successful.
However, this is no longer good enough, because NOX performs
admission control on connections after sending a number of OpenFlow
messages, in particular after doing OpenFlow version negotiation and
requesting the switch features (and receiving the reply). Thus, this
commit adjusts the heuristic by only considering certain OpenFlow
messages to demonstrate that admission control checks have passed and
thus that the connection should be considered successful.
As a fallback, any connection that persists for 30 seconds or longer is
also considered successful.
An alternate and complementary approach (that this commit does not
implement) would be to use an OpenFlow error message to indicate why
the connection is closing.
Fixes bug #239.
rconn_destroy() decrements the n_queued counters that are set up by
rconn_send(), so we need to destroy the rconn before we destroy anything
that used it.
(This system is more error-prone than I imagined.)
If an invalid port index was used in dp_set_origin, the value of skb->dev
was left unchanged. This change causes skb->dev to be set to NULL in those
circumstances. This makes Packet Out and Add Flow messages that use a
buffer id behave like Packet Out without a buffer id.
When a buffer id is placed in a Flow Mod message, the actions are expected to
be executed against the referenced packet. The kernel implementation was
not setting the input device to what the controller was telling it to use.
Thanks to Natasha for catching this.
Ben Pfaff
Justin Pettit