Bugzilla – Bug 777
AODV ignores specified outgoing interface in RouteOutput()
Last modified: 2010-03-01 04:49:55 UTC
AODV does not do anything with the oif parameter, which may be set by Socket::BindToDevice(). This was changed from an interface index to a device pointer, but AODV has not been handling this parameter yet. Ptr<Ipv4Route> RoutingProtocol::RouteOutput (Ptr<Packet> p, const Ipv4Header &header, Ptr<NetDevice> oif, Socket::SocketErrno &sockerr) Note: AODV also has issues with RouteOutput in bug 772 so I am going to mark depends on. Maybe RouteOutput() function for AODV is a moot point.
If bug 772 is handled by passing a DeferredRouteRequest tag from RouteOutput to RouteInput, should the tag also carry the bound device information so that RouteOutput knows the outbound device constraint?
(In reply to comment #1) > If bug 772 is handled by passing a DeferredRouteRequest tag from RouteOutput to > RouteInput, should the tag also carry the bound device information so that > RouteOutput knows the outbound device constraint? Yes, I guess if route is not known and oif != 0 in RouteOutput, it should be tagged and then tagged packet is queued in DeferredRouteOutput and when route is finally established tag is removed (if any) and output device is substituted in SendPacketFromQueue. If you agree I will implement this behavior after bug 772 fix will be accepted.
(In reply to comment #2) > (In reply to comment #1) > > If bug 772 is handled by passing a DeferredRouteRequest tag from RouteOutput to > > RouteInput, should the tag also carry the bound device information so that > > RouteOutput knows the outbound device constraint? > > Yes, I guess if route is not known and oif != 0 in RouteOutput, it should be > tagged and then tagged packet is queued in DeferredRouteOutput and when route > is finally established tag is removed (if any) and output device is substituted > in SendPacketFromQueue. If you agree I will implement this behavior after bug > 772 fix will be accepted. By the way, could anybody contribute test case for this bug to src/routing/aodv/test ?
(In reply to comment #2) > (In reply to comment #1) > > If bug 772 is handled by passing a DeferredRouteRequest tag from RouteOutput to > > RouteInput, should the tag also carry the bound device information so that > > RouteOutput knows the outbound device constraint? > > Yes, I guess if route is not known and oif != 0 in RouteOutput, it should be > tagged and then tagged packet is queued in DeferredRouteOutput and when route > is finally established tag is removed (if any) and output device is substituted > in SendPacketFromQueue. If you agree I will implement this behavior after bug > 772 fix will be accepted. I agree, with the only question being whether the RREQ/RREP code will consider whether oif != 0 and wait for a reply that matches oif? The two alternatives seem to be 1) just let AODV do its thing normally, but discard the route (route failure) if the found route doesn't match oif, or 2) pass over routes that don't match oif, waiting for one that does. 2) seems to be more robust but it seems that it might lead to the internal routing table storing routes in tuples of (oif, dst), which I don't know whether it is worth the effort. I agree that a test case would be nice for all three of these related bugs (777-779) but I can't get to it at the moment.
> I agree, with the only question being whether the RREQ/RREP code will consider > whether oif != 0 and wait for a reply that matches oif? The two alternatives > seem to be 1) just let AODV do its thing normally, but discard the route (route > failure) if the found route doesn't match oif, or 2) pass over routes that > don't match oif, waiting for one that does. 2) seems to be more robust but it > seems that it might lead to the internal routing table storing routes in tuples > of (oif, dst), which I don't know whether it is worth the effort. I agree that second alternative looks more reasonable, but this is definitely an extension of aodv RFC. I propose to implement "weak" alternative #1 and return to this point if it will be reported to fail in some useful setup. (btw, bind to device socket option looks exotic to me, what real problem forced you to open all that bugs?) > I agree that a test case would be nice for all three of these related bugs > (777-779) but I can't get to it at the moment.