Before, if a hub connected a number of OpenFlow switches and the controller,
then in-band control traffic from one of the OpenFlow switches would be
seen by each of the other switches and forwarded up to the controller as
an ofp_packet_in message. That message would then be seen by all of the
other OpenFlow switches and also forwarded, and so on in an infinite loop.
This change prevents this situation by keeping secchan from forwarding
ofp_packet_in messages for a packet destined to the controller that
arrives on the port where the controller is located.
This code has at least two weaknesses. First, if the controller's port
changes, then the flows set up to drop packets will not be deleted. This
should not be a major problem: if this inadvertently kills a switch's
connection to the controller, then the switch will realize it after it
stops receiving data and re-connect. Its new connection will have new
flow data and therefore its packets will not be dropped.
Second, the notion of the "controller's port" does not take into account
the possibility of loops in the network topology. We need spanning tree
protocol for that.
Some callers want to just test whether the device has an address assigned
and don't care about the particular address, so this simplifies those
callers slightly.
The learning switch functionality included in OpenFlow will send packets
out the port they arrived on if the learned destination is from that port.
This causes problems when newer switches flood packets for destinations they
don't know and OpenFlow reinjects packets back into the network. The correct
behavior is to just drop the packet.
When a vconn reports an error, the rconn would not reliably reconnect.
In particular, if the error was reported after the call to rconn_run()
but before rconn_run_wait() was called, then the state's "run" routine
would not set min_timeout properly, leading to a potentially arbitrarily
long wait (depending on what other events were going on in) until the
state's "run" routine was called again.
The fix is to have a separate per-state "timeout" routine to compute
when the state needs to be re-entered.
This commit was tested using the following change to randomly inject
errors:
@@ -554,11 +554,16 @@
static int
try_send(struct rconn *rc)
{
int retval = 0;
struct buffer *next = rc->txq.head->next;
- retval = vconn_send(rc->vconn, rc->txq.head);
+ if (!random_range(1000)) {
+ fprintf(stderr, "injecting ECONNRESET\n");
+ retval = ECONNRESET;
+ } else {
+ retval = vconn_send(rc->vconn, rc->txq.head);
+ }
if (retval) {
if (retval != EAGAIN) {
disconnect(rc, retval);
}
return retval;
Before, the amount of time disconnected was measured relative to the
last time we connected, that is, the last time connect(2) succeeded.
Thus, if we were connected for a long time, and then disconnected,
we would immediately go into fail-open mode.
This change make the disconnected time relative to the last OpenFlow
message received. Thus, if we are connected for a long time and
receive plenty of packets, and then disconnect, there will still be
an opportunity to reconnect before failing open.
This was in there because at one time it seemed desirable to configure
from the postinst, but that idea was abandoned. Now Debconf seems to
be screwing something up somehow, so we might as well not run it at all,
since it wasn't doing anything useful.
This fixes "module-assistant auto-install openflow-datapath" for
bootstrapping from a clean environment. (Use "m-a -f purge
openflow-datapath" to test that it works starting from an un-clean
environment.)
Generating them unconditionally caused a problem with the init script:
the script required there to be a certificate for the private key if
the private key existed, but we do want to allow TCP-only configurations
and always having a private key prevented that.
Also, give the user advice on how to deal with this problem when it
arises in the init script.
We use SIGALRM to limit runtime of dpctl and ofp-discover. There is no
reason that we should not clean up after it in the same way as any other
catchable signal. In particular, ofp-discover wants to restore network
device flags on timeout.
Ben Pfaff
Justin Pettit
Natasha Gude