That's what I thought. I was wondering about the scenario where I might want to do the following:
(1) grovel inside an ARP-Reply packet for the address being resolved; (2) do an RadixIPLookup() on that address (3) locate the appropriate ARPQuerier instance based on that lookup; (4) forward that ARP-Reply to the appropriate ARPQuerier instance. Being purely packet-oriented is somewhat limiting, since more complex operations that modify the packet flow might need to be the composite result of several primitive steps, as above. On 1/9/11 10:55 AM, Eddie Kohler wrote: > Hi Philip, > > I read the rest of this thread but just to respond to the top level question. > > Elements don't really "RETURN" anything. They are parts of a packet-oriented > dataflow. > > The ingress interface of a packet is accessible from within C++, however. > For the full interface to Packet: > > http://read.cs.ucla.edu/click/doxygen/classPacket.html > > You want Packet::device_anno(). > > Eddie > > > On 1/1/11 12:26 PM, Philip Prindeville wrote: >> (Forgive the newbie questions... I'm having to learn Click in a hurry as I >> ramp up on a project.) >> >> Is there a built-in element that returns the ingress interface of a packet? >> >> I'm trying to write an elementclass in Click that modifies a packet and then >> sends it back out the same interface it came in on, but don't want to have >> one instance of it per-interface that it is used on. >> >> Thanks. >> >> -Philip >> >> _______________________________________________ >> click mailing list >> [email protected] >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
