d80211: allow for large scan results

net/d80211/ieee80211_ioctl.c static int ieee80211_ioctl_add_if(struct · line 1091

Quoted 11 lines · David Kimdon

net/d80211/ieee80211_ioctl.c +10 -0

+	if (param->u.if_info.type == HOSTAP_IF_WDS) {
+		type = IEEE80211_IF_TYPE_WDS;
+	} else if (param->u.if_info.type == HOSTAP_IF_VLAN) {
+		type = IEEE80211_IF_TYPE_VLAN;
+	} else if (param->u.if_info.type == HOSTAP_IF_BSS) {
+		type = IEEE80211_IF_TYPE_AP;
+	} else if (param->u.if_info.type == HOSTAP_IF_STA) {
+		type = IEEE80211_IF_TYPE_STA;
+	} else {
+        return -EINVAL;
 	}

IMHO that'd look better as a switch(). Or maybe even a small static array to map them and just some bounds checking code?

ARM targets support udelay(N) where N <= 2000.
Use mdelay() when N >= 2000.

Signed-off-by David Kimdon <[email protected]>

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
===================================================================

drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c +0 -0

 	} else {
 		if (bcm->current_core->rev < 5)
 			return 0;

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
===================================================================

This ioctl is used when radar is delected on a channel. Data frames must stop but management frames must be allowed to continue for some time to communicate the channel switch to stations.

+ ret = ieee80211_ioctl_set_stop_data_frame_tx(dev, value);

Should that really drop dataframes dead on the floor? And wouldn't it make sense stop the networking layer from injecting more data into the stack when stop_data_frame_tx is enabled?

Quoted 3 lines · Johannes Berg

Should that really drop dataframes dead on the floor? And wouldn't it make sense stop the networking layer from injecting more data into the stack when stop_data_frame_tx is enabled?

I agree. That should be solved in an another way (stop dequeuing frames from 802.11 qdisc?).

This ioctl is used when radar is delected on a channel. Data frames must stop but management frames must be allowed to continue for some time to communicate the channel switch to stations.

+static int ieee80211_ioctl_set_stop_data_frame_tx(struct net_device

+ ret = ieee80211_ioctl_set_stop_data_frame_tx(dev,
+ value);

Quoted 3 lines · David Kimdon

This ioctl is used when radar is delected on a channel. Data frames must stop but management frames must be allowed to continue for some time to communicate the channel switch to stations.

Which does lead to the question: How are you detecting radar in userspace in the first place??

Radar is initially detected by the low-level radio driver. Userspace gets notified of radar via calls to ieee80211_radar_status, which generates a "fake" management frame with a struct ieee80211_radar_info in it. Userspace is then responsible for handling the resultant activities, such as stopping transmission on that channel, selecting another channel, sending out channel switch announcements, changing channels, and remembering to block use of the old channel for the required time.

Quoted 8 lines

Radar is initially detected by the low-level radio driver. Userspace gets notified of radar via calls to ieee80211_radar_status, which generates a "fake" management frame with a struct ieee80211_radar_info in it. Userspace is then responsible for handling the resultant activities, such as stopping transmission on that channel, selecting another channel, sending out channel switch announcements, changing channels, and remembering to block use of the old channel for the required time.

I think that would warrant a new netlink multicast group and doing over nl80211 to start with ;) Inserting fake management frames into the mgt interface sounds pretty weird to me.

Quoted 3 lines · Johannes Berg

I think that would warrant a new netlink multicast group and doing over nl80211 to start with ;) Inserting fake management frames into the mgt interface sounds pretty weird to me.

I concur -- inserting frames is a neat hack, but not the preferred way for the long haul.

What would be the preferred way of doing the conversion here? I think I would prefer to get the radar detection code in as-is and then move all the messages to use a new mechanism as one change once that mechanism becomes available.

hostapd connection uses number of these frames which are actually not fake management frames, but just frames with different "pseudo header" on the management interface. You can search for ieee80211_msg_ types to see the different types of status messages that are used.

Quoted 4 lines · Jouni Malinen

What would be the preferred way of doing the conversion here? I think I would prefer to get the radar detection code in as-is and then move all the messages to use a new mechanism as one change once that mechanism becomes available.

I suppose that depends on how quickly you want these things :) nl80211 is there for review and I suppose if a bunch of people actually build things on top of it we can merge it. As it stands, we could merge it and then start building too, if a few more people review it maybe.

Quoted 4 lines

hostapd connection uses number of these frames which are actually not fake management frames, but just frames with different "pseudo header" on the management interface. You can search for ieee80211_msg_ types to see the different types of status messages that are used.

Yeah, I know. Does anyone else use these or can we simply drop this after conversion?

Well, it would be nice to get these in quite soon. I know that the current mechanism works since it has been used for years, but if the netlink-based solution is considered stable and working and unlikely to require major changes soon, I don't have anything against using it here.

Once there is mechanism to replace all the current functionality, I would just drop it. There is some meta information, like signal strength, in the header, so this does not only include event notifications, but also additional data for frames.

This ioctl is used when radar is delected on a channel. Data frames must stop but management frames must be allowed to continue for some time to communicate the channel switch to stations.

There is one other application where data frames should be buffered - in a client while roaming between 2 APs. The best way to implement this will be to extend the 802.11 qdisc. Currently there are 4 queues, representing the 4 EDCA access categories. Only the top AC (AC_VO) is used for sending management frames. I would recommend we split the qdisc, so that there are 2 software queues attached to this AC - one for management frames and 802.1x, and another for data frames. This way if we want to stop data (either for radar, or because we are mid BSS transition) we can simply stop all the queues except the AC_VO management queue.