On Sat, Jan 27, 2007 at 12:44:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:

In article [ref] (at Fri, 26 Jan 2007 09:27:30 -0500), Neil Horman [off-list ref] says:

quoted

I'm looking for it at the moment, but I too had assumed that redirecting the
outgoing packet to the default router would happen automatically within the
routing code as a result of not having a completed neighbor entry available.
Since I've modified ndisc_send_ns such that we will never send Neighbor
solicitations from an optimistic address, as per section 3.2, we'll never get a
completed neightbor entry while the address is optimistic.  If thats not the
case, I'd welcome some suggestions on how to implement this (given that I'm not
overly familiar with the code right now).  From what I see, I think the routing
code will select the default route when rti6_nexthop is null during route
selection, which it will be if the neighbor entry doesn't get resolved.  Not
100% sure though.  Let me know what you think.

(Now I remember that I hit similar issue before when I once
tried to implement this....)

Well... no, you cannot assume that routing code solves this issue.
This is not so trivial, and I am not aware clean solution yet...

On reason of this issue is because the source address may not be
probided by user, and the source address selection will be done
after looking up routing table.

One possibiliy is to solve by rt->rt6i_nexthop->output(),
but I guess we will hit some race condition.

Hmm...

Is this perhaps something we can do in ip6_output2?  We can test the interface
flags there and if the interface is optimistic, we can lookup the default route
(perhaps via rt6_lookup, using the unspecified address for the daddr), and then
replace skb->dst with the dst_entry retrieved from the lookup, which should give
us the proper mac header construction starting in ip6_output_finish.

What do you think?
Neil