> > 1. The bogus diagnostic message is due to a bug in Nevada, > > covered by 6781883. I've added this fix to my IPMP wad. > > If this is one of our own messages, then we shouldn't get to > ip_ndp_conflict, because dl_mp should be NULL at this point. dl_mp is > non-NULL only when there's a DL_UNITDATA_IND available, which should > happen only with multicast packets arriving from the outside world. > > At least that's how it *used* to work.
Good point. I think this subtlety was lost on me when I was doing some rework of the code many moons ago and the dl_mp == NULL check was lost in ndp_input_advert(). I can and will add that check back, as it's simpler. I will add a more detailed comment for the 'dl_mp == NULL' check so that no one else gets lost in here. That said, I'd like to keep the changes to ip_ndp_find_solicitation(), as there are still cases where that function may be passed an advertisement and parse it like it's a solicitation (e.g., an NA from the wire shouldn't always be going through the IFT_ETHER logic). -- meem
