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
