Don't special-case broadcast packets in in-band mode.

Before, in in-band mode, the secure channel would flood all flows
destined for the broadcast destination when not connected to a
controller.  The rationale was that this allowed for ARP replies
to be forwarded to the local port, so that the secure channel
could obtain the Ethernet address of the controller.  But this
is a false rationale: ARP replies are unicast to the requester,
not broadcast. (Frames unicast to the local port are always handled
by the secure channel.)

Also, even if it were a correct rationale, it would not help in
at least one case: if the controller's Ethernet address has expired
from the ARP cache, but the secure channel's TCP connection to
the controller is still connected, then the secure channel attempt
to ARP would fail, since the broadcast ARP reply would not be
handled by the secure channel (since the secure channel thought
that it was still connected).

diff --git a/secchan/secchan.c b/secchan/secchan.c
index 08002143115cb2e6991093d91dc4bb957b11c896..037cc7682937a7718a31259f4e9618161073a9f1 100644 (file)
--- a/secchan/secchan.c
+++ b/secchan/secchan.c
@@ -396,10 +396,7 @@ local_hook(struct relay *r)
     flow_extract(&pkt, in_port, &flow);
 
     /* Deal with local stuff. */
-    if (!rconn_is_connected(r->halves[HALF_REMOTE].rconn)
-        && eth_addr_is_broadcast(flow.dl_dst)) {
-        out_port = OFPP_FLOOD;
-    } else if (in_port == OFPP_LOCAL) {
+    if (in_port == OFPP_LOCAL) {
         out_port = mac_learning_lookup(local_ml, flow.dl_dst);
     } else if (eth_addr_equals(flow.dl_dst, local_mac)) {
         out_port = OFPP_LOCAL;