patch-2.1.15 linux/net/bridge/br.c

• Lines: 46
• Date: Thu Dec 12 16:54:23 1996
• Orig file: v2.1.14/linux/net/bridge/br.c
• Orig date: Tue Nov 19 15:53:59 1996

diff -u --recursive --new-file v2.1.14/linux/net/bridge/br.c linux/net/bridge/br.c
@@ -14,6 +14,7 @@
  *	2 of the License, or (at your option) any later version.
  *
  *	Fixes:
+ *		Yury Shevchuk	:	Bridge with non bridging ports
  *
  *	Todo:
  *		Don't bring up devices automatically. Start ports disabled
@@ -1202,7 +1203,13 @@
 				return(0);	/* pass frame up our stack (this will */
 						/* happen in net_bh() in dev.c) */
 			}
-			/* ok, forward this frame... */
+			/* Now this frame came from one of bridged
+			   ports, and it appears to be not for me;
+			   this means we should attempt to forward it.
+			   But actually this frame can still be for me
+			   [as well] if it is destined to one of our
+			   multicast groups.  br_forward() will not
+			   consume the frame if this is the case */
 			return(br_forward(skb, port));
 		default:
 			printk(KERN_DEBUG "br_receive_frame: port [%i] unknown state [%i]\n",
@@ -1238,6 +1245,11 @@
 	if (skb->dev->flags & IFF_LOOPBACK)
 		return(0);
 
+	/* if bridging is not enabled on the port we are going to send
+           to, we have nothing to do with this frame, hands off */
+	if (! find_port(skb->dev))
+		return(0);
+
 	skb->h.raw = skb->data;
 	port = 0;	/* an impossible port */	
 	if (br_stats.flags & BR_DEBUG)
@@ -1331,6 +1343,10 @@
 }
 
 /*
+ * Forward the frame SKB to proper port[s].  PORT is the port that the
+ * frame has come from; we will not send the frame back there.  PORT == 0
+ * means we have been called from br_tx_fr(), not from br_receive_frame().
+ *
  * this routine returns 1 if it consumes the frame, 0
  * if not...
  */