> However, here, ill_resolver_mp is not a DL_UNITDATA_REQ, but an areq_t,
> because of this code in ill_dl_up():
>
> areq_mp = ill_arp_alloc(ill,
> (uchar_t *)&ip_areq_template, 0);
> if (areq_mp == NULL) {
> return (ENOMEM);
> }
> freemsg(ill->ill_resolver_mp);
> --> ill->ill_resolver_mp = areq_mp;
>
> As per the proposed fix, in ip_newroute() we will set nce_state to
> ND_REACHABLE and call nce_fastpath() -> ill_fastpath_probe(), but
It gets a little confusing because the ire_dlureq_mp is
used for both dl_unitdata requests and responses, but I think what you
are saying is that when we reinit the nce, we have a dl_unitdata *request*
(not the response) in the nce, so that we really cannot force the nce_state
to be ND_RECHABLE at this point. right?
The real solution is to eliminate the allow_unresolved hack, and figure
out what to do for cgtp. In the case of cgtp, I think the assert at
line 30020 of ip_xmit_v4 was triggered once during testing. I believe it
is ok to trigger this assert, but I would have to re-examine the cgtp
assumptions to do this part.
As things stand, clearly the allow_unresolved is really not working at all,
since we can hit this path for cgtp packets as well.
> ill_fastpath_probe() expects a dl_unitdata_req_t in nce_res_mp, not an
> areq_t. The result is that we send a completely bogus DL_IOC_HDR_INFO
> message down to the driver, which means it returns EINVAL and and
> nce_fp_mp remains NULL. Also, nce_res_mp continues to point to an areq_t
> rather than a dl_unitdata_req_t -- but ip_wput_ire() doesn't know this, so
> it happily sends bogus "DL_UNITDATA_REQ" messages to the driver, (with
> dl_primitive set to 0x4103 aka AR_ENTRY_QUERY), causing the driver to send
> up a DL_ERROR_ACK each time IP attempts to send a packet.
>
> Thoughts?
