On Fri, 2007-08-10 at 14:01 +0100, 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'm not sure why you have to restrict the devices to DL_ETHER only. I
think you can allow DL_WIFI devices if-and-only-if the device is
STA/client mode.
- Garrett
>
> Thoughts?
>
> dme.
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
