[ Old thread, but I've been meaning to ask. ] > 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"? -- meem