On Wed, 2015-12-16 at 05:13 -0800, Ben Greear wrote: > On 12/16/2015 01:17 AM, Johannes Berg wrote: > > On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote: > > > This patch below was added to the kernel around 2/24/2015 > > > > > > I am curious mostly about the first change: I thought the > > > transmitter-addr relates to the radio device, not the vdev (sta, > > > ap, > > > etc). > > > > It doesn't, even on real hardware. > > No, I mean that the HWSIM_ATTR_ADDR_TRANSMITTER should relate to the > radio, and not the vdev, see the mac80211_hwsim.h: > > * @HWSIM_ATTR_ADDR_TRANSMITTER: MAC address of the radio device that > * the frame was broadcasted from I think that just means the documentation is misleading. Clearly, the TA (hdr->addr2) is intended and implemented. "radio device" is a bit of a misleading term when you have virtual interfaces. > Since we are asking user-space to provide HWSIM_ATTR_ADDR_TRANSMITTER, > then we can use that to find the radio device. Then, normal mac80211 > logic can handle finding the vdevs (just as it does for ath9k). Oh. So you're basically arguing that we should treat it as a cookie, and on outgoing frames give the hardware address, and on incoming frames use it only to look up the struct mac80211_hwsim_data. > And in this case, there is no reason to have more than one address > associated with the hwsim radio device. We could add a pretty simple > hash to keep the lookup near constant time instead of linear search > as the current behaviour is... Yeah, ok, that would be (have been) doable I guess. We'd still have the real TA in the frame itself (hdr->addr2). > I think that wmediumd should keep it's own mapping of what radio > a vdev is on and use the proper hwsim radio addr for the > HWSIM_ATTR_ADDR_TRANSMITTER attribute. That's somewhat difficult for it, since it could only populate that mapping on actual TX frames. I think this is pretty much a done deal by now though since I don't really want to break wmediumd. If we wanted to go this route I think we should be more explicit and simply use the HWSIM_ATTR_RADIO_ID attribute. We could support that easily - just see if the RADIO_ID is present and look up the transmitter (or receiver btw) radio based on the RADIO_ID if present - that gives a clean path forward too since wmediumd can be taught to specify both knowing the kernel will prefer the radio ID if present. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
