On 16 Nov 2007, at 6:00am, Peter Memishian wrote: > [ Old thread, but I've been meaning to ask. ]
I should declare that I didn't implement either of the approaches suggested, as the difficulties in having Wifi links support multiple unicast addresses threw me a curve. When I have to go back to this I'd expect to have the VNIC code expose the true details of the underlying link. >> 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. > > It may be straightforward, but it seems like it would eventually > lead to > problems. For instance, how would a technology like Infiniband be > supported? Are we also going to make it look like DL_ETHER? How much > work would be involved in option (2)? Also, how large is the set > of "all > VNIC mac clients" that would need to "cook as required"? As others indicated, any code that directly opens mac devices (by calling mac_open()) is likely to need support for cook/uncook operations. Right now that's a set something like dls, vsw, aggr, vnic and xnbo. The code is not complex, but knowing that it's required is the first step :-) dme. -- David Edmondson, Solaris Engineering, http://dme.org
