[patch 1/5] d80211: allow for large scan results

[patch 1/5] d80211: allow for large scan results

[David Kimdon]

[-- Attachment #1: scan_length.patch --]
[-- Type: text/plain, Size: 1461 bytes --]

Fix a problem where incomplete scan results could be returned if the
environment includes a large number of devices.  Do not truncate the
scan results and allow a result to contain more than IW_SCAN_MAX_DATA
bytes.

Signed-off-by: David Kimdon <david.kimdon@devicescape.com>

Index: wireless-dev/net/d80211/ieee80211_sta.c
===================================================================
--- wireless-dev.orig/net/d80211/ieee80211_sta.c
+++ wireless-dev/net/d80211/ieee80211_sta.c
@@ -2753,6 +2753,10 @@ int ieee80211_sta_scan_results(struct ne
 	spin_lock_bh(&local->sta_bss_lock);
 	list_for_each(ptr, &local->sta_bss_list) {
 		bss = list_entry(ptr, struct ieee80211_sta_bss, list);
+		if (buf + len - current_ev <= IW_EV_ADDR_LEN) {
+			spin_unlock_bh(&local->sta_bss_lock);
+			return -E2BIG;
+		}
 		current_ev = ieee80211_sta_scan_result(dev, bss, current_ev,
 						       end_buf);
 	}
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===================================================================
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1998,7 +1998,7 @@ static int ieee80211_ioctl_giwscan(struc
 	struct ieee80211_local *local = dev->ieee80211_ptr;
 	if (local->sta_scanning)
 		return -EAGAIN;
-	res = ieee80211_sta_scan_results(dev, extra, IW_SCAN_MAX_DATA);
+	res = ieee80211_sta_scan_results(dev, extra, data->length);
 	if (res >= 0) {
 		data->length = res;
 		return 0;

--

[patch 2/5] d80211: fix multiple device support

[David Kimdon]

[-- Attachment #1: dev_alloc_name-retval.patch --]
[-- Type: text/plain, Size: 660 bytes --]

Fix interpretation of dev_alloc_name() return value.  dev_alloc_name()
returns the number of the unit assigned or a negative errno code.

Signed-off-by: David Kimdon <david.kimdon@devicescape.com>

Index: wireless-dev/net/d80211/ieee80211_iface.c
===================================================================
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -64,7 +64,7 @@ int ieee80211_if_add(struct net_device *
 		} while (i < 10000);
 	} else if (format) {
 		ret = dev_alloc_name(ndev, name);
-		if (ret)
+		if (ret < 0)
 			goto fail;
 	} else {
 		snprintf(ndev->name, IFNAMSIZ, "%s", name);

--

[patch 3/5] d80211: fix interface removal

[David Kimdon]

[-- Attachment #1: remove-if-type.patch --]
[-- Type: text/plain, Size: 1382 bytes --]

Calls to ieee80211_if_remove() should use the ieee80211 interface types.
Convert interface type from hostapd to ieee80211 format.

Signed-off-by: David Kimdon <david.kimdon@devicescape.com>

Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===================================================================
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1076,14 +1076,21 @@ static int ieee80211_ioctl_add_if(struct
 static int ieee80211_ioctl_remove_if(struct net_device *dev,
 				     struct prism2_hostapd_param *param)
 {
-	if (param->u.if_info.type != HOSTAP_IF_WDS &&
-	    param->u.if_info.type != HOSTAP_IF_VLAN &&
-	    param->u.if_info.type != HOSTAP_IF_BSS &&
-	    param->u.if_info.type != HOSTAP_IF_STA) {
-                return -EINVAL;
+	unsigned int type;
+
+	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;
 	}
-	return ieee80211_if_remove(dev, param->u.if_info.name,
-				   param->u.if_info.type);
+
+	return ieee80211_if_remove(dev, param->u.if_info.name, type);
 }
 
 

--

Re: [patch 3/5] d80211: fix interface removal

[Johannes Berg]

On Tue, 2006-08-22 at 10:33 -0700, David Kimdon wrote:
> +	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?

Also, spaces instead of tab on the last added line.

johannes

Re: [patch 3/5] d80211: fix interface removal

[Jiri Benc]

On Wed, 23 Aug 2006 09:20:28 +0200, Johannes Berg wrote:
> On Tue, 2006-08-22 at 10:33 -0700, David Kimdon wrote:
> > +	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?

You're right, but I'm taking the patch anyway. It's resembling the code
of ieee80211_ioctl_add_if. Both of these function can be converted to
use switches later by one patch.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

[patch 4/5] d80211/bcm43xx: fix build for ARM

[David Kimdon]

[-- Attachment #1: bcm43xx-udelay.patch --]
[-- Type: text/plain, Size: 1206 bytes --]

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

Signed-off-by: David Kimdon <david.kimdon@devicescape.com>

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
@@ -291,7 +291,7 @@ int bcm43xx_pctl_set_crystal(struct bcm4
 		err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCTL_OUT, out);
 		if (err)
 			goto err_pci;
-		udelay(5000);
+		mdelay(5);
 	} else {
 		if (bcm->current_core->rev < 5)
 			return 0;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
@@ -1687,7 +1687,7 @@ int bcm43xx_radio_selectchannel(struct b
 	radio->channel = channel;
 	//XXX: Using the longer of 2 timeouts (8000 vs 2000 usecs). Specs states
 	//     that 2000 usecs might suffice.
-	udelay(8000);
+	mdelay(8);
 
 	return 0;
 }

--

Re: [patch 4/5] d80211/bcm43xx: fix build for ARM

[Michael Buesch]

On Tuesday 22 August 2006 19:34, David Kimdon wrote:
> ARM targets support udelay(N) where N <= 2000.
> Use mdelay() when N >= 2000.
> 
> Signed-off-by: David Kimdon <david.kimdon@devicescape.com>
> 
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
> ===================================================================
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
> @@ -291,7 +291,7 @@ int bcm43xx_pctl_set_crystal(struct bcm4
>  		err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCTL_OUT, out);
>  		if (err)
>  			goto err_pci;
> -		udelay(5000);
> +		mdelay(5);

I am going to convert this to msleep anyway. (Patch is almost done)
So please drop this hunk.

>  	} else {
>  		if (bcm->current_core->rev < 5)
>  			return 0;
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
> ===================================================================
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_radio.c
> @@ -1687,7 +1687,7 @@ int bcm43xx_radio_selectchannel(struct b
>  	radio->channel = channel;
>  	//XXX: Using the longer of 2 timeouts (8000 vs 2000 usecs). Specs states
>  	//     that 2000 usecs might suffice.
> -	udelay(8000);
> +	mdelay(8);
>  
>  	return 0;
>  }

Well, yeah. Please resubmit this patch with only this hunk.
I don't like that long delay here. I am searching for a good
solution, but I think we should live with it for now.

-- 
Greetings Michael.

[patch 5/5] d80211: add ioctl to stop data frame tx

[David Kimdon]

[-- Attachment #1: stop_data_frame_tx.patch --]
[-- Type: text/plain, Size: 2889 bytes --]

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.

Signed-off-by: David Kimdon <david.kimdon@devicescape.com>

Index: linux-2.6.16/net/d80211/hostapd_ioctl.h
===================================================================
--- linux-2.6.16.orig/net/d80211/hostapd_ioctl.h
+++ linux-2.6.16/net/d80211/hostapd_ioctl.h
@@ -93,6 +93,7 @@ enum {
 	PRISM2_PARAM_SPECTRUM_MGMT = 1044,
 	PRISM2_PARAM_USER_SPACE_MLME = 1045,
 	PRISM2_PARAM_MGMT_IF = 1046,
+	PRISM2_PARAM_STOP_DATA_FRAME_TX = 1047,
 	/* NOTE: Please try to coordinate with other active development
 	 * branches before allocating new param numbers so that each new param
 	 * will be unique within all branches and the allocated number will not
Index: linux-2.6.16/net/d80211/ieee80211.c
===================================================================
--- linux-2.6.16.orig/net/d80211/ieee80211.c
+++ linux-2.6.16/net/d80211/ieee80211.c
@@ -1240,6 +1240,15 @@ static int ieee80211_tx(struct net_devic
 		return 0;
 	}
 
+	if (unlikely(local->stop_data_frame_tx)) {
+		struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+		u16 fc = le16_to_cpu(hdr->frame_control);
+		if ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA) {
+			dev_kfree_skb(skb);
+			return 0;
+		}
+	}
+
 	__ieee80211_tx_prepare(&tx, skb, dev, control);
 	sta = tx.sta;
 	tx.u.tx.mgmt_interface = mgmt;
Index: linux-2.6.16/net/d80211/ieee80211_i.h
===================================================================
--- linux-2.6.16.orig/net/d80211/ieee80211_i.h
+++ linux-2.6.16/net/d80211/ieee80211_i.h
@@ -532,6 +532,8 @@ struct ieee80211_local {
 				* (1 << MODE_*) */
 
 	int user_space_mlme;
+	int stop_data_frame_tx; /* Set to 1 to stop transmission
+				 * of data frames. */
 };
 
 enum ieee80211_link_state_t {
Index: linux-2.6.16/net/d80211/ieee80211_ioctl.c
===================================================================
--- linux-2.6.16.orig/net/d80211/ieee80211_ioctl.c
+++ linux-2.6.16/net/d80211/ieee80211_ioctl.c
@@ -1300,6 +1300,14 @@ static int ieee80211_ioctl_set_radio_ena
         return ieee80211_hw_config(dev);
 }
 
+static int ieee80211_ioctl_set_stop_data_frame_tx(struct net_device *dev,
+					  	  int val)
+{
+	struct ieee80211_local *local = dev->ieee80211_ptr;
+        local->stop_data_frame_tx = val;
+        return 0;
+}
+
 static int
 ieee80211_ioctl_set_tx_queue_params(struct net_device *dev,
 				    struct prism2_hostapd_param *param)
@@ -2612,6 +2620,9 @@ static int ieee80211_ioctl_prism2_param(
 	case PRISM2_PARAM_USER_SPACE_MLME:
 		local->user_space_mlme = value;
 		break;
+	case PRISM2_PARAM_STOP_DATA_FRAME_TX:
+                ret = ieee80211_ioctl_set_stop_data_frame_tx(dev, value);
+		break;
 	default:
 		ret = -EOPNOTSUPP;
 		break;

--

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Johannes Berg]

On Tue, 2006-08-22 at 10:34 -0700, David Kimdon wrote:

> 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??

> +       if (unlikely(local->stop_data_frame_tx)) {
> +               struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> +               u16 fc = le16_to_cpu(hdr->frame_control);
> +               if ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA) {
> +                       dev_kfree_skb(skb);
> +                       return 0;
> +               }
> +       }

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?

> +static int ieee80211_ioctl_set_stop_data_frame_tx(struct net_device *dev,
> +                                                 int val)
> +{
> +	struct ieee80211_local *local = dev->ieee80211_ptr;
> +        local->stop_data_frame_tx = val;
> +        return 0;
> +}

Again, whitespace damaged. Yes, I know it's hard to code in there with
any smart editor that thinks it knows what to do based on the
surroundings because those may also contain whitespace...


> +                ret = ieee80211_ioctl_set_stop_data_frame_tx(dev, value);

Ditto.

johannes

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Jiri Benc]

On Wed, 23 Aug 2006 09:25:06 +0200, Johannes Berg wrote:
> 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?).

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Elliot Schwartz]

Hi Jiri (and Johannes),

Jiri Benc <jbenc@suse.cz> writes:
> On Wed, 23 Aug 2006 09:25:06 +0200, Johannes Berg wrote:
> > 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 is used to be able to send the channel switch announcements that
are queued from userspace out, yet not send dataframes in this same
queue out. This is to avoid exceeding regulatory requirements for
transmission time after radar has been detected.

It's not ideal, but possibly neither is hanging on to the frames
during the interval in which the channel changes hoping to find the
same station there.

Thanks,

elliot

RE: [patch 5/5] d80211: add ioctl to stop data frame tx

[Simon Barber]

David - how long does the data flow need to be stopped when radar is
detected? If it's a short time it would be better to buffer the data
frames, if the connection can be disabled for a long time then dropping
them might be better.

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.

Simon


-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Johannes Berg
Sent: Wednesday, August 23, 2006 12:25 AM
To: David Kimdon
Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch 5/5] d80211: add ioctl to stop data frame tx

On Tue, 2006-08-22 at 10:34 -0700, David Kimdon wrote:

> 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??

> +       if (unlikely(local->stop_data_frame_tx)) {
> +               struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)
skb->data;
> +               u16 fc = le16_to_cpu(hdr->frame_control);
> +               if ((fc & IEEE80211_FCTL_FTYPE) ==
IEEE80211_FTYPE_DATA) {
> +                       dev_kfree_skb(skb);
> +                       return 0;
> +               }
> +       }

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?

> +static int ieee80211_ioctl_set_stop_data_frame_tx(struct net_device
*dev,
> +                                                 int val) {
> +	struct ieee80211_local *local = dev->ieee80211_ptr;
> +        local->stop_data_frame_tx = val;
> +        return 0;
> +}

Again, whitespace damaged. Yes, I know it's hard to code in there with
any smart editor that thinks it knows what to do based on the
surroundings because those may also contain whitespace...


> +                ret = ieee80211_ioctl_set_stop_data_frame_tx(dev, 
> + value);

Ditto.

johannes
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Elliot Schwartz]

Hi Johannes,

Johannes Berg <johannes@sipsolutions.net> writes:
> On Tue, 2006-08-22 at 10:34 -0700, David Kimdon wrote:
> > 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??

I've been working on merging Devicescape's 802.11h / radar detection
implementation into the open source hostapd (and the wireless-dev kernel). 

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'll reply to your and Jiri's other question separately.

Thanks,

elliot

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Johannes Berg]

Hi Elliot,

Thanks for the explanation.


> 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.

johannes

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[John W. Linville]

On Tue, Aug 29, 2006 at 09:30:57AM +0200, Johannes Berg wrote:

> > 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.

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

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Jouni Malinen]

On Tue, Aug 29, 2006 at 07:45:23AM -0400, John W. Linville wrote:
> On Tue, Aug 29, 2006 at 09:30:57AM +0200, Johannes Berg wrote:

> > 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.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Johannes Berg]

On Tue, 2006-08-29 at 11:39 -0700, Jouni Malinen wrote:

> 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.

> 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?

johannes

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Jouni Malinen]

On Wed, Aug 30, 2006 at 09:26:21AM +0200, Johannes Berg wrote:
> On Tue, 2006-08-29 at 11:39 -0700, Jouni Malinen wrote:
> 
> > 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.

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.

> > 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?

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.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Johannes Berg]

On Wed, 2006-08-30 at 09:01 -0700, Jouni Malinen wrote:

> 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.

:)
May I ask you to take a look at nl80211 to see if it matches your
expectations/needs? It obviously needs to be expanded and we may want to
add some multicast groups that applications can subscribe to for scan
results/radar detection/management frames/...
What really should be done soon is implementing transmit status
notification for injected packets since injection is already working. I
just happen to not need it at the moment and have a bunch of other
things to do.

> 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.

That meta information can be transmitted through other channels too
though :)

johannes

Re: [patch 5/5] d80211: add ioctl to stop data frame tx

[Jiri Benc]

On Tue, 22 Aug 2006 10:34:19 -0700, David Kimdon wrote:
> 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.

Any progress here? Is what Simon wrote (quoted below) reasonable? (It seems
so to me.)

Anybody volunteers to implement this? ;-)

On Wed, 23 Aug 2006 12:20:16 -0700, Simon Barber wrote:
> 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.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs