Hello I am not a subscriber to this list, but I felt it may be a good place to post this question. I am creating user-space Linux implementation of AODV, an ad-hoc networking routing protocol. I have three computers (A, B, C) configured with wireless interfaces, all on the same subnet, with the connectivity illustrated below: A <-----> B <-----> C For "A" to communicate with "C" it has to send out a route request (RREO). The RREQ is answered by "B" since it has a route to "C". When "A" is waiting for a reply it buffers any packets going to "C". I do this with the netfilter hooks NF_IP_LOCAL_OUT and NF_IP_PRE_ROUTING, holding on any packets to "C". These hooks capture packets before any routing is performed. Node "A" receives the reply that it can communicate with "C" via "B" and therefore adds the route to "C" to the kernel routing table with an ioctl call (SIOCADDRT). Then "A" starts to send any queued packets and let new packets get through. The idea is that the packets should be routed on the newly added entry in the routing table. The problem is that some of the, up to about 6, first packets (generated with ping), is not sent to "B", but directly to C instead, resulting in unresolvable ARP requests and eventually "Destination Host Unreachable". After a second or so, packets are routed through "B" as they should, although the first packets are lost. If I monitor the routing cache of "A" I can see a "C->C" entry created for a second or so before it is updated to "C->B", even though the "C->B" entry exists in the FIB beforehand. I have tried to flush the routing cache by writing a "0" to /proc/sys/net/ipv4/route/flush both before and after the route is added by the daemon and I have also played with all the timer and delay values available in /proc/sys/net/ipv4/route and /proc/sys/net/ipv4/neigh and so on. Some settings seemed to improve the situation, i.e. less packets are routed directly to "C", but I have been unsuccessful in eliminating the problem entirely. >From my observations I have drawn the conclusion that the newly added route is not immediately acknowledged by the kernel's routing code. I hope someone on this list can shed some light on this issue, or even better, come up with a solution. Regards, Erik Nordström - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html