Joonwoo, I will try that tomorrow. Most likely the packets won't be visible to tcpdump then as your patch registers a new netdev_rx_handler.
Roman On 05/11/2011 05:04 PM, Joonwoo Park 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_Internals/ >> >> 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
