[Click] Patchless kernel click problem

[Roman Chertov]

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