[let me take both your emails at once] > > That is _very_ dangerous. If the user has older firmware that doesn't > > know about WSC2, how would the user know not to configure WSC2 in > > hostapd? That needs to be known to hostapd so it can verify this > > situation. For P2P, we already know whether or not P2P is supported, but > > that's rather vague in case there will ever be a revision of the P2P > > spec with say different IEs. > > Well basically the FW should white-list probe-requests it knows about > and pass up all the rest. Indeed. But we need to know what things the firmware knows about, so we can disable additional functionality automatically. > > IMHO it would be smarter to rework the firmware to only reply to probe > > requests if the probe response is configured. Then, if WSC, P2P, or > > similar technologies are in use on the interface, hostapd can simply > > decide to not configure the probe response and have host-based > > processing. Would that be a change you could still make? > > With the current set of patches the decision is left at the hands of > the driver/fw. Hostapd currently doesn't have a way of toggling > probe-resp offloading in the low level driver. > This kind of plumbing is not needed in case the FW handles what it can > and passes up unknown probe-requests. Well, it could trivially have this functionality by simply not setting the SSID/probe response frame -- older hostapd would "automatically" not use this feature, and you'd even have a good upgrade path -- the feature is only used for new hostapd, and then only when hostapd knows that it is possible to use the feature. > Its also conceivable that an old driver/fw won't work when some > protocol is changed/updated, even if hostapd supports it. > I'm not sure the probe-resp will be the culprit here.. Indeed. But in such cases, we've dealt with it. But with a simple update like for example WSC 3.0 (which I don't think is being planned yet, but may eventually be written) your approach would certainly require a firmware update. I think that's a bit undesirable, but I'm not saying that you _need_ to change the firmware. I'm merely recommending that if the firmware doesn't know the SSID, it will pass up all probe requests. It has to have the "pass up" functionality already for P2P/WSC2, so that could trivially be extended to pass up when the driver sets a certain bit to request it always. It's been pointed out to me that maybe I'm not always communicating things effectively -- so let me try to write a summary of the entire thing again: The way you're implementing this feature right now _relies_ on the firmware to do the right thing for all protocols. However, hostapd/wpa_supplicant have no way of knowing what protocols the firmware knows about, and they will almost certainly be extended for more protocols in the future. This I don't want to see -- I want you to advertise in nl80211 what protocols (including their versions) the firmware knows about, so that a future hostapd can automatically disable new protocols that the firmware doesn't know about. I'm also _recommending_ that you change the firmware implementation to guard against that and be more backward compatible: allow the driver to set a bit meaning "pass up all probe requests". Yes, that will destroy host power savings obtained by this feature if enabled, but will allow hostapd/wpa_s to implement new features and one could then actually at least test, if not use, them with the older device. You could also get rid of the beacon parsing code etc. and simply require that a modern hostapd that implements the offload be used for maximum power saving. 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
