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. Thoughts? dme.
