> However, as part of the discussion from friday, we force the nce to
> be REACHABLE after step #4, and this causes confusion later when we
> try triggering fastpath without a properly constructd dl_unitdata response
> in the nce_res_mp.
>
> So one way of fixing this is to modify the change discussed earlier,
> and only force the nce_state to ND_REACHABLE after #4 if the nce has the
> dl_unitdata_response in it, but this is a messy fix.
>
> It is probably cleaner to re-examine and straighten out the
> allow_unresolved argument.
That summary seems correct. I just removed the use of allow_unresolved
from ire_add_v4() in my workspace (and removed the previous fix we arrived
at on Friday), and so far, so good. When I flush the IRE cache and then
attempt to send a packet to an off-link host, I hit ire_arpresolve() with
the following (seemingly reasonable) stack:
ip`ire_arpresolve+4
ip`ip_xmit_v4+0x444
ip`ip_wput_ire+0x19b0
ip`ire_send+0x2a8
ip`ire_add_then_send+0x354
ip`ip_newroute+0xce8
ip`ip_output_options+0x1e98
ip`ire_send+0x218
ip`ire_add_then_send+0x354
ip`ip_output_options+0x1260
putnext+0x3ec
arp`ar_query_reply+0x168
arp`ar_ce_resolve+0xb8
arp`ar_ce_resolve_all+0x110
arp`ar_rput+0x3f4
putnext+0x3ec
ce`ce_intr+0x68cc
--
meem
