Hi, > Okay, that makes things easier. However, it does bring up a > question. Should we be symmetric and remove AP_VLAN as a valid target > of control port frames? E.g. drop NL80211_IFTYPE_AP_VLAN case in > patch 2 of the series. In effect we'd require all control port > frame traffic to go over the master interface. Yeah, I think that'd make sense. > I'm the one confused now. You wanted me to add IFTYPE_IBSS in > nl80211_tx_control_port in your earlier feedback :) Hah. My memory is like a sieve... > Let me try to restate what I said earlier in a different way and see > if it makes things a bit clearer: > > So in patch 9, we set sdata->control_port_over_nl80211 based on > parameters passed into start_ap or mgd_assoc. The > control_port_over_nl80211 flag is passed in cfg80211_crypto_settings > structure that is part of the relevant parameters structure. If > sdata->control_port_over_nl80211 is true, then we actually redirect > the control port frames to nl80211. Right. > So my question is, if we want to support IBSS/MESH, should we: > 1. add the whole cfg80211_crypto_settings to the IBSS/MESH > parameters, > 2. add the control_port_over_nl80211 flag directly to IBSS/MESH > parameters > 3. Pass the flag some other way? > 4. Or drop IBSS/MESH from patch 2 (nl80211_tx_control_port) > completely? I'd say 2 or 4. Having all the crypto settings would be confusing, since they aren't (and possibly cannot) be used. 4 is a bit annoying - not that I remember - because it eventually means that when we do want to support it in IBSS/MESH, we'd have to add another flag indicating that now it's supported, etc. But I think we can live with that too, if it's too complex to add this for real. johannes
