[Click] Handlers

[Michael Voorhaen]

Never mind people,

Apparently String doesn't implement operator<<, so that's why It always
printed wrong. I just called c_str() and it was ok. Sorry if I put some
people on the wrong track, but I'm pretty new with click and am not 100%
familiar with the code. Anyways, thanks for the help so far.

Michael

On Tue, 3 Feb 2004, 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>
>
>