Hi Lars, Lars Bro wrote: > Hi Eddie > > I am working on a test bench for our product, and I use a server with > several network interfaces where I send packets on one interface and > then listen where and when these packets arrive. Basically, I have > written a "Correlator" element that keeps packets arriving on input 0 > for a certain time and checks packets arriving on all other inputs > against these. The output is packets with correlation information: > packet # xxx with paint anno yyy were seen on these input ports at with > these delays. > The correlation output is sent as UDP via ToHost to the recording > application. > > So, I can do with "FromDevice", "ToDevice" and "ToHost". > > I certainly think that the "unmodified" kernel is the way to go, and > would very much like to help testing it. > > One question, though: So far, I have intercepted a network connection by > using two ports, and configuring a bridge "brctl addbr..." When loading > Click, the bridge stops working, but of course FromDevice ... ToDevice > is used within the Click configuration to make the same bridge with > whatever interception is needed. I guess it is a bad idea to have the > bridge module loaded at all, or will Click still be able to "take over" > somehow?
So I believe that Click will take over from the bridge module, although any bridge that you've set up will stop working -- Click ignores the "brctl". Nevertheless, it will be safer to run without the bridge module loaded. Eddie > > yours, > Lars Bro > > On Thu, Feb 11, 2010 at 2:08 AM, Eddie Kohler <[email protected] > <mailto:[email protected]>> wrote: > > Hi Lars, > > My plan for the future is to further develop the linuxpatchless > infrastructure, which lets us run Click on unmodified kernels. > > So I would love for people to test this, such as you. Let us know > how it goes. The only thing missing that I know of is FromHost. > > Eddie > > > Lars Bro wrote: > > Hi, > > I am using Click for testing of our wireless product, and I > experience an > increasing demand for support of newer kernels. The reason for > this is > hardware of course, but also wireless(802.11) drivers have been > changing a > lot lately. > > I am now working with Matteo Croce's patches for 2.6.31 (on > 2.6.31.9), this > is not as easy as I had thought. I can also see that Adam > Greenhalgh has > done some work in separating syntax changes from core changes. > > What I would like to know is whether this kind of work is > already ongoing, > or if there is an official plan for the next kernel patch. > > As I can see, Matteo's patch also includes changes for Click > itself, and > this should be very carefully considered. > > So I suggest that we agree on a "next" kernel version to > support, so we can > work on it in common. > > Any votes? > > yours, > Lars Bro > _______________________________________________ > click mailing list > [email protected] <mailto:[email protected]> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
