--- linux/net/bridge/br_forward.c.lennert	2003-01-07 16:36:18.000000000 -0500
+++ linux/net/bridge/br_forward.c	2003-01-07 16:36:18.000000000 -0500
@@ -20,11 +20,42 @@
 #include <linux/if_bridge.h>
 #include <linux/netfilter_bridge.h>
 #include "br_private.h"
+#include <string.h>
+
+
+inline int isWlan(char *ifname) {
+  char *c = ifname + 4;
+  if (ifname == NULL) return 0;
+  if (strncmp(ifname, "wlan", 4)) return 0;
+  while (*c) {
+    if ((*c < '0') || (*c > '9')) return 0;
+    ++c;
+  }
+  return 1;
+}
+
 
 static inline int should_deliver(struct net_bridge_port *p, struct sk_buff *skb)
 {
-	if (skb->dev == p->dev ||
-	    p->state != BR_STATE_FORWARDING)
+
+/*
+ *     Marty Lamb 01/06/2003
+ *     modified forwarding decision to be based upon the combination of the
+ *     data's incoming physical device and bridge port number rather than the
+ *     physical device alone. 
+ *
+ *     Joe Parks 01/07/2003
+ *     Add an exception for devices named wlanX as these need special help
+ *     bridging to associated STAs.
+ */
+ 
+        if ( ( (skb->dev == p->dev)
+	        && ( (skb->dev->br_port == NULL)
+		     || (skb->dev->br_port->port_no == p->port_no)
+		   ) 
+		&& (!isWlan(skb->dev->name))
+              )
+	      || (p->state != BR_STATE_FORWARDING))
 		return 0;
 	return 1;

On Friday 04 June 2004 16:32, Karel Rericha wrote:

> Tom Marshall wrote:
  

> > It seems to me that detecting interfaces by name is a Very Bad Idea.
> > There
> > should be (if there is not already) a way to detect wireless devices
> > without
> > relying on the device name.  The wireless extension code manages.
    

>
> Agreed, that's why it is against my mind to use it. I expect that the
> whole "--resend-on-iif" idea is not
> about bounding this functionality to wireless only interfaces, but to
> allow let user decide which interface
> needs retransmit packets back (interfaces for physical devices where
> individual stations are not allowed
> to transmit packets directly on physical layer are good example).
>
> Hoping the patch will be easy and Bart or others will find a time to
> make it soon.
  

Is there any reason to make the decision to retransmit on the same interface 
on a per-packed basis? I mean, wouldn't it be better to just make it a bridge 
option per bridge port?
Implementing something like this with ebtables will be hairy because the 
packets that need to be retransmitted need to be marked somehow, which would 
mean some fooling around with the skbuff members (the nf_bridge member isn't 
necessarily available).

cheers,
Bart
*************************************************************************
Bart De Schuymer wrote:

Is there any reason to make the decision to retransmit on the same interface on a per-packed basis? I mean, wouldn't it be better to just make it a bridge option per bridge port?
 

Implementing something like this with ebtables will be hairy because the packets that need to be retransmitted need to be marked somehow, which would mean some fooling around with the skbuff members (the nf_bridge member isn't necessarily available).

cheers,
Bart

 

On Friday 04 June 2004 20:16, Stephen Hemminger wrote:
 

Rather than hacking the bridge code and risking routing loops and other
nasty's, why not change the wireless driver to have a "reflect all packets"
flag?
 

Some devices which appear as one single interface to Linux are really some kind of (wireless?) bridge with many ports. If I understood correctly, more control over what this hardware forwards is wanted. The hardware can be made to give the packets to Linux instead of bridging them, but after Linux has played with the packets, they should go back to that hardware. A way to do this is make a bridge port out of this interface and force the bridge code to deliver the packets back to the input bridge port.
AFAIK the requested functionality (being able to filter, tc, etc. the packets) can't be implemented by only altering the driver code.

cheers,
Bart

 

On Thursday 01 July 2004 15:49, Karel Rericha wrote:

In the previous discussion on the ebtables-devel mailing list it was decided 
that there is no need to make the decision per packet, which means this 
functionality belongs in the bridging code and not in ebtables.

cheers,
Bart
*************************************************************************
*************************************************************************

Sorry for maybe too much reading for so simple option :)