[Click] Handlers

[Michael Neufeld]

I haven't been building grid in my nsclick environment, but am planning on doing 
a full click CVS update at some point this week and give it a whirl. Another 
thought on setting the next hop ethernet address would be to use the packet 
annotation space to pass along the destination ethernet address to a custom 
element which cooks up the full header. I've done that a couple of times when I 
wanted to keep my ethernet address lookup and encapsulation elements separate -
worked just fine as long as I had enough unused annotation bytes to spare.

-Mike

Douglas S. J. De Couto wrote:

> Hi Michael,
> 
> Sorry, I started looking at your grid/nsclick problem, but then got 
> swamped.
> 
> I use EtherAddress all the time, and haven't seen any problem with its 
> s() method, perhaps you can send an example of the problem?
> 
> Can you describe the seg fault with more detail -- where does it occur?
> 
> The general approach you describe seems like it should work, although 
> you might get better performance by writing the ethernet destination 
> address in your own element (which is what Grid/DSDV does), or using a 
> more ARP-like element (either the click IP ARP elements, or something 
> like the Grid DSRArpTable).  The EtherEncap element isn't designed to be 
> very dynamic, but you could write one like it with set_dest() and 
> set_src() C++ methods that your element could call directly.
> 
> On 3 Feb 2004, at 11:15, Michael Voorhaen wrote:
> 
>> Hi,
>>
>> I sent an e-mail last week, stating that I had problems compiling grid 
>> for
>> nsclick and haven't seen an answer yet.
>>
>> I've skipped getting grid to work for a while and started implementing 
>> the
>> hierarchical protocol that I've been working on (based on hierarchical 
>> state
>> routing). Basically to concept is to implement the hierarchical 
>> protocol on
>> top of a (slightly modified) flat routing protocol. I've started
>> implementing this top down, so I only needed some stubs where the flat
>> protocol is required and I can debug that software as quick as 
>> possible. Now
>> somewhere in my click graph I have this situation:
>>
>>     [GetNextHop]     ----> 0: [EtherEncap]
>>                  ---->    1: [Discard]
>>
>> The GetNextHop element is one that I implemented. It determines the 
>> next hop
>> for the packet (stub code for now). Now what I want to happen than is 
>> that
>> EtherEncap encapsulates the IP packet with the correct destination 
>> Ethernet
>> address in the Ethernet header. So for that I need to pass the next hop
>> Ethernet address to EtherEncap. I want to do this with handlers, so I 
>> gave
>> EtherEncap a name and obtained a pointer to it in the GetNextHop code. So
>> far so good. I then get the handler object "dst":
>>
>> In GetNextHop.push();
>>         This->router()->handler("dst", _etherEncap);
>>
>> _etherEncap points to the EtherEncap object.
>>
>> This gets me the handler, and then I call call_write( next_hop_ether.s(),
>> _etherEncap,_errh);
>>
>> This causes a segmentation fault.
>>
>> Now I've been trying to narrow down the problems and I found this:
>>     * there is something wrong with how EtherAddress creates the string
>> representation of the address (check it out, if you have the time).
>>     * even when I replace next_hop_ether.s() (which is not computed
>> correctly) with an actual ethernet address that works when manually
>> configured in a click file, I still get the segmentation fault.
>>
>> I could really use some help here. By the way, I'm using the CVS 
>> version of
>> click.
>>
>> Regards,
>> Michael Voorhaen
>>
>> ========================================================
>> Michael Voorhaen
>> ========================================================
>> Phd Student
>> Dept. of Mathematics and Computer Sciences
>> PATS (Performance Analysis of Telecommunication Systems)
>> University of Antwerp
>> Middelheimlaan 1
>> 2020 Antwerpen, Belgium
>> G1.11
>> Phone: 03/2653905
>> Mail: michael.voorhaen at ua.ac.be
>> ========================================================
>>
>>
>>
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
> -- 
> Douglas S. J. De Couto    <decouto at csail.mit.edu>
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click