Created attachment 916 [details]
Simulation scripts reproducing the bug

Important notes:
* this behavior does not occur always: specifically, only for some seeds AODV fails to establish a route.
* Also, I am not sure if this bug is related to bug 879 (in that bug TCP is used, whereas here UDP is used).

I saw that AODV cannot establish a correct route for the following configuration:
* OnOffApplication + UDP
* WifiAdHoc multi-hop network w/ chain topology: OnOffApp on 1st node, PacketSink on n-th node
* ~200 seconds of simulation

Here's an excerpt of a gdb session:
Breakpoint 6, ns3::UdpSocketImpl::DoSendTo (this=0x80b7a00, p=..., dest=..., port=21) at ../src/internet-stack/udp-socket-impl.cc:430
430	      route = ipv4->GetRoutingProtocol ()->RouteOutput (p, header, oif, errno_); 
(gdb) bt
#0  ns3::UdpSocketImpl::DoSendTo (this=0x80b7a00, p=..., dest=..., port=21) at ../src/internet-stack/udp-socket-impl.cc:431
#1  0xb76a6bea in ns3::UdpSocketImpl::DoSend (this=0x80b7a00, p=...) at ../src/internet-stack/udp-socket-impl.cc:271
#2  0xb76a6ee8 in ns3::UdpSocketImpl::Send (this=0x80b7a00, p=..., flags=0) at ../src/internet-stack/udp-socket-impl.cc:249
#3  0xb75d2ce9 in ns3::Socket::Send (this=0x80b7a00, p=...) at ../src/node/socket.cc:112
#4  0xb77e4e2e in ns3::OnOffApplication::SendPacket (this=0x80aa7b8) at ../src/applications/onoff/onoff-application.cc:240
#5  0xb77e2f14 in Notify (this=0x80a4f78) at debug/ns3/make-event.h:94
#6  0xb745694a in ns3::EventImpl::Invoke (this=0x80a4f78) at ../src/simulator/event-impl.cc:37
#7  0xb74764aa in ns3::DefaultSimulatorImpl::ProcessOneEvent (this=0x807add0) at ../src/simulator/default-simulator-impl.cc:128
#8  0xb747650a in ns3::DefaultSimulatorImpl::Run (this=0x807add0) at ../src/simulator/default-simulator-impl.cc:158
#9  0xb745f915 in ns3::Simulator::Run () at ../src/simulator/simulator.cc:173
#10 0x08052858 in main (argc=2, argv=0xbffff3c4) at ../scratch/aodv.cc:138
(gdb) n
431	      if (route != 0)
(gdb) p route
$6 = {
  m_ptr = 0x80b5eb0
}
(gdb) p/x (*route->m_ptr)
$7 = {
  <ns3::SimpleRefCount<ns3::Ipv4Route, ns3::empty, ns3::DefaultDeleter<ns3::Ipv4Route> >> = {
    <ns3::empty> = {<No data fields>}, 
    members of ns3::SimpleRefCount<ns3::Ipv4Route, ns3::empty, ns3::DefaultDeleter<ns3::Ipv4Route> >: 
    m_count = 0x1
  }, 
  members of ns3::Ipv4Route: 
  m_dest = {
    m_address = 0xa000005
  }, 
  m_source = {
    m_address = 0x66666666
  }, 
  m_gateway = {
    m_address = 0x7f000001
  }, 
  m_outputDevice = {
    m_ptr = 0x80a26d8
  }
}

By translating the addresses, it is possible to see that the destination is 10.0.0.5 (correct), the source is 102.102.102.102 (not correct), and the gateway is 127.0.0.1 (not correct).

I have attached a simulation script that reproduces the bug (in my case using --RngRun=10 turns on the bug).
To find a "bug-enabling" seed one could use a quick'n'dirty for-loop in bash (hitting ctrl-c whenever packet are received):
for i in $(seq 1 2000) ; do ./waf --command-template="%s --RngRun=$i" --run "scratch/aodv" ; done