Fwd: [Click] ToDevice + ARP woes

[John Bicket]

Were you guys using kernel click?  I would think for projects and most
things that userlevel click would be fine, and a lot easier to debug.

Can you send what wasn't working for ARPResponder (ie the packet in
hex)?

Are there specific examples of sample configurations that you think
would help?  There are the examples at
http://www.pdos.lcs.mit.edu/click/ex/
but a lot of them were written to show how to do something very specific 
rather than how to understand writing configurations.

--john


Eddie Kohler [kohler at cs.ucla.edu] wrote:
>John Austen gave me permission to forward this...
>
>
>Begin forwarded message:
>
>>From: John Austen <deymious at yahoo.com>
>>Date: November 28, 2004 1:27:35 PM PST
>>To: Eddie Kohler <kohler at CS.UCLA.EDU>
>>Subject: Re: [Click] ToDevice + ARP woes
>>
>>Yep, I'm also part of the Rutgers class. The
>>assignment is now complete, but in the interest of
>>advancing Click!...
>>
>>No, we didn't have the capability to alter the kernel
>>code, in fact all the elements that would require a
>>kernel recompile (like FromHost) were not available.
>>
>>Right up until the end I had very interesting behavior
>>from ARP. The ARPResponder would have valid ARP
>>requests sent to it, via a Classifier, but would not
>>respond to the requests. Even more oddly, this did not
>>stop me from getting the packets being sent to the
>>Ethernet.
>>
>>After postponing the project deadline three times the
>>assignment's goals were sharply reduced and the class
>>handed in their projects as-is. One of the biggest
>>problems was our infrastructure; the virtual machines
>>needed to be tunneled to and these would go down
>>relatively often. One other very large stumbling block
>>I am sad to say was the Click! documentation. In many
>>places it was startlingly incomplete. Since Click!
>>does not have logical elements (if, then, variables)
>>that allow the programmer to create their own logic,
>>the programmer must be able to bulid their
>>functionality out of the provided elements. To do this
>>effectively very strong, careful, requirements for
>>input and guarantees for output need to be made. I
>>realize Click! is experimental and is indeed a work in
>>progress, but it would benefit greatly from extended
>>documentation. Two examples: the IPEncap element calls
>>for an unsigned integer to determine what protocol to
>>make the encapsulating packet, the example given in
>>the documentation is 4, 'IP in IP', however nowhere do
>>any other values appear. I had to troll through the
>>source code in order to find the 79 other protocol
>>specifiers. The FromSimDevice element has the
>>following documentation to explain its function: 'This
>>manual page describes the user-level version of the
>>FromSimDevice element.'
>>
>>Unfortunately I had to make multiple trips through the
>>source code, learn quite a bit about the gory details
>>of Linux networking and its kernel, and run hosts of
>>tests in order to determine the exact functionality of
>>some elements... resulting twice in the crashing of
>>the virutal machines we were working on, as well as
>>almost two solid weeks of work in order to provide
>>relatively simplistic functionality.
>>
>>The unit programming model certainly is attractive for
>>cases like coding network devices, and I do realize
>>Click! is not meant for wide-scale commercial release,
>>but I believe that with greatly expanded documentation
>>it would be much easier to use.
>>
>>
>>
>>
>>		
>>__________________________________
>>Do you Yahoo!?
>>The all-new My Yahoo! - Get yours free!
>>http://my.yahoo.com
>>
>
>_______________________________________________
>click mailing list
>click at amsterdam.lcs.mit.edu
>https://amsterdam.lcs.mit.edu/mailman/listinfo/click