I think you've already seen responses to this from others. GLDv2 used to call this, so NIC drivers do not have to start their attach with their unicast addresses programmed.
GLDv3 no longer calls this on attach, only if the administrator attempts to change the MAC address. This means your driver must arrange to start with its own unicast address at attach/registration time. This is a change for GLDv3. -- Garrett Steve Stallion wrote: > (Apologies for the cross-post, I have been having little luck resolving this) > > All, > > I've noticed something very peculiar while running tests on the GLDv3 > dnet. Normally when running tests I have snoop running in the > background; I ran the same bevy of tests again, this time without > snoop effectively testing non-promiscuous behavior. The interface > stopped sending and receiving packets; dtrace probes were not being > fired. > > Essentially, it appeared the NIC was only functioning in promiscuous > mode. I immediately suspected that perhaps the address for the device > was not being set correctly. Upon closer inspection, during a plumb > and subsequently setting an inet4 address, dtrace revealed that the > mc_unicst callback was never being called - only mc_multcst. > > Is this correct behavior? Should I manually call mac_unicst_refresh or > mac_unicst_update when the device is initialized (i.e. in dnet_start) ? > > TIA, > > Steve > _______________________________________________ > networking-discuss mailing list > [email protected] > _______________________________________________ networking-discuss mailing list [email protected]
