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 <[email protected]> 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 <[email protected]> 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 > > > [email protected] > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > > > _______________________________________________ > > click mailing list > > [email protected] > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
