David Edmondson wrote: > I'm looking at 6579770 (VNICs over wpi: corrupted inbound, nothing > out). There are really two parts to the problem: > > * The VNIC driver presents a 'pure' DL_ETHER device upward, regardless > of the downstream device (which in this case is <DL_ETHER, > DL_WIFI>). > * Most wireless NICs will only transmit packets with their assigned > MAC address as a source address when in "client" mode. > > The first of these could be fixed in two ways: > > * Have the VNIC driver continue to present a pure DL_ETHER device > upwards and manage the header cooking as necessary, > * Have the VNIC driver properly reflect the type of the underlying > device and have all VNIC mac clients deal with cooking as required. > > Implementing the first of these two options was straightforward, so > that's what I did. > > The second problem seems more difficult to address. From reading > around, removing the restriction requires an update to the firmware > for the wireless NIC. This is not likely to be possible in all cases. > > So, what to do? The options are: > > 1. Disallow non-pure DL_ETHER underlying devices when creating VNICs. > 2. Allow non-pure DL_ETHER underlying devices, knowing that many > (most? all?) of them won't actually produce a working VNIC. > > For the second case, a decision about whether to hide the fact that > they are non-pure is required, but not so urgent. > > I'm inclined to go for option 1, particularly as that reduces the risk > for the Xen project integration into Nevada. It's always possible to > come back later and revisit, obviously.
I agree, I would suggest going with option 1. I don't think we should allow combinations which could fail randomly depending on the hardware used. If we could express that wireless NIC limitation through a capability exported by the wireless driver, then we could have the VNIC driver and the MAC layer check for that limitation and "gracefully fail" the VNIC creation operation if the wireless NIC underneath doesn't support that capability. I think we should be able to provide information about that capability through dladm show-* as well. Something else to consider is that in the future we are planning to allow multiple VNICs to share a single MAC address. It seems that this could be used to properly support the wireless NICs with these limitation. This feature could kick in automatically for NICs which don't support sending packets with multiple source MAC addresses, in this case either for all DL_WIFI or for the DL_WIFI drivers with that limitation. Nicolas. > > Thoughts? > > dme. > _______________________________________________ > xen-discuss mailing list > xen-discuss at opensolaris.org -- Nicolas Droux - Solaris Networking - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux
