[Click] Patchless kernel click problem

[Roman Chertov]

Joonwoo,

I pulled from your tree and tested out on vanilla 2.6.37.6 kernel.  The same
tcpdump behavior occurs as when using the br_handle (i.e. click and tcpdump both
get the packet).  On the plus side, it means that we have a capture mechanism
for 2.6.37+ kernels as br_handle is no longer present in those versions.

Roman

On Wed, 11 May 2011 17:04:24 -0700 Joonwoo Park <joonwpark81 at gmail.com> wrote

> Hi Roman,
> 
> Have you had a chance to test with 2.6.37 with the patches here
> https://github.com/kohler/click/pull/12 ?
> The patch uses another way to steal packet from linux as linux 2.6.37
> doesn't expose bridge packet hooking point.
> I haven't seriously looked how it impacts to this behaviour but it's
> possible 2.6.37 with that patch is different.
> 
> Joonwoo
> 
> On Wed, May 11, 2011 at 4:45 PM, Roman Chertov <rchertov at cs.ucsb.edu> wrote:
> >
> > So I did some digging and according to the diagram in the link below,
> > the observed behavior is correct.
> >
> >
> >
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_I
> > nternals/
> >
> > Prior to passing frames to the br_handle_frame_hook, the frames are
> > duplicated and sent to the registered sniffers.  However, once the
> > frames are sent to the bridge handler they are not supposed to be passed
> > to any protocols.  I did a few tests with arping and it does appear that
> > the IP stack does not receive the frames once Click is running.
> > However, the ARP requests can still be seen via tcpdump, confirming the
> > behavior shown in the diagram.
> >
> > Roman
> >
> >
> >
> >
> > On 05/06/2011 09:40 AM, Roman Chertov wrote:
> > > So I spent some time on the issue I reported earlier with packets being
> > > visible
> > > to the kernel IP stack when running kernel level Click.  I have installed
> > > a
> > > plain vanilla kernel 2.6.35.9 on my Fedora14 box, and ran the following
> > > config.
> > >
> > > FromDevice(eth12) ->  Print ->  Discard;
> > >
> > > I have also ran tcpdump -i eth12.  The packets that were sent to the
> > > machine
> > > were captured by tcpdump, which definitely should not have happened.
> > >  Looks like
> > > the br_handle_frame_hook capture method gets the packets after they get
> > > on the
> > > way to the kernel IP stack.  This behavior is definitely not good for
> > > some
> > > kernel level configs as the kernel IP stack should not be involved in
> > > packet
> > > processing at all.
> > >
> > > By the way, Joonwoo reported the same issue on his Ubuntu setup.
> > >
> > > Roman
> > >
> > >
> > > _______________________________________________
> > > click mailing list
> > > click at amsterdam.lcs.mit.edu
> > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> > >
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click