[ovs-dev] [PATCH 08/26] ofproto: Allow reception of packets from a tunnel tundev

Simon Horman horms at verge.net.au
Sun Jun 3 23:25:53 UTC 2012


This is to cope with the situation where an ICMP reply is generated
by the tunneling code in the datapath in which case the input port
will be a tunnel tundev which has no bundle.

Cc: Kyle Mestery <kmestery at cisco.com>
Signed-off-by: Simon Horman <horms at verge.net.au>

---

v5
* No Change

v4
* No Change

v3
* Initial posting
---
 ofproto/ofproto-dpif.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index cccaea5..dc050bf 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -6116,6 +6116,12 @@ lookup_input_bundle(const struct ofproto_dpif *ofproto, uint16_t in_port,
         return &ofpp_none_bundle;
     }
 
+    if (ofport->tun) {
+        VLOG_WARN("bridge %s: received packet on tundev "
+                  "port %"PRIu16, ofproto->up.name, flow->in_port);
+        return &ofpp_none_bundle;
+    }
+
     /* Odd.  A few possible reasons here:
      *
      * - We deleted a port but there are still a few packets queued up
@@ -6161,7 +6167,7 @@ is_admissible(struct ofproto_dpif *ofproto, const struct flow *flow,
         return false;
     }
 
-    if (in_bundle->bond) {
+    if (in_bundle && in_bundle->bond) {
         struct mac_entry *mac;
 
         switch (bond_check_admissibility(in_bundle->bond, in_port,
-- 
1.7.10.2.484.gcd07cc5




More information about the dev mailing list