handle_bridge does call the tap, so my question is answer there. thanks,
On 4/24/07, Laurent Chavey <[EMAIL PROTECTED]> wrote:
On 4/23/07, jamal <[EMAIL PROTECTED]> wrote: > On Mon, 2007-23-04 at 16:08 -0700, Laurent Chavey wrote: > > sorry for the trick question. > > > > I was simply making a modification to the skb tap code > > to allow tcpdump to work on the slave interface and not > > just the bonded one. > > If you dont mind: what is the goal? I am not sure i want to see the > packets on a backup interface in a bond active/backup - but you may > have some good reason. this is for an lacp type bond where packets can come on any of the bond links and we need to check for the exact link. > > > The code change requires a change to > > the for loop code and it follow on to the call to deliver_skb(). > > > > Iam assuming you have taken care of the code above that which drops the > packet if not destined for master? yes > > > In the process of adding the code, I noticed that if (at least > > that is how I read the code) > > CONFIG_NET_CLS_ACT is not defined then > > the last pt_prev is call after the diverter and bridge code > > have handled the skb. This would only occur for bridged skb > > that one wanted to tap. > > > > The bridge code does the right thing if you follow handle bridge. > The old diverter (you must be looking at an old kernel, because it is > gone) was supposed to be able to steal packets. > I am not sure if that answers your question. > given 2 skb, both bridged (stolen) by the bridge code, if CONFIG_NET_CLS_ACT is not defined, then it looks like that only the first skb would be taped, the second one never makes it to the tap. > cheers, > jamal > > >
- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
