netdev - Re: is CONFIG_NET_CLS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1177372977.4096.24.camel@localhost>
Date:	Mon, 23 Apr 2007 20:02:57 -0400
From:	jamal <hadi@...erus.ca>
To:	Laurent Chavey <chavey@...gle.com>
Cc:	netdev@...r.kernel.org
Subject: Re: is CONFIG_NET_CLS_ACT always set ?

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.

> 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? 

> 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.

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html