[PATCH 1/2] mac80211: enabling an AP that can't support fully PS clients (wireless-testing).

[PATCH 1/2] mac80211: enabling an AP that can't support fully PS clients (wireless-testing).

[Rami Rosen]

This patch enables mac80211 to support the PS challenged mode when
used in master mode.
A new attribute, NL80211_ATTR_WIPHY_AP_PS_CHALLENGED, was added to
nl80211_attrs; also a new member (ap_ps_challenged) was added to
struct wiphy; and nl80211_send_wiphy() was adjusted accordingly.

User space applications (like hostapd) should check the
NL80211_ATTR_WIPHY_AP_PS_CHALLENGED
attribute and  display a proper message, if it is set, to inform the
users.

Signed-off-by: Rami Rosen <ramirose@gmail.com>

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 7982734..dbe15e0 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -256,6 +256,9 @@ enum nl80211_commands {
  *	supported interface types, each a flag attribute with the number
  *	of the interface mode.
  *
+ * @NL80211_ATTR_WIPHY_AP_PS_CHALLENGED: indicates that the wiphy support
+ *  for PS is not full.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -316,6 +319,8 @@ enum nl80211_attrs {

 	NL80211_ATTR_WIPHY_TXQ_PARAMS,

+	NL80211_ATTR_WIPHY_AP_PS_CHALLENGED,
+
 	/* add attributes here, update the policy in nl80211.c */

 	__NL80211_ATTR_AFTER_LAST,
@@ -329,6 +334,7 @@ enum nl80211_attrs {
 #define NL80211_ATTR_HT_CAPABILITY NL80211_ATTR_HT_CAPABILITY
 #define NL80211_ATTR_BSS_BASIC_RATES NL80211_ATTR_BSS_BASIC_RATES
 #define NL80211_ATTR_WIPHY_TXQ_PARAMS NL80211_ATTR_WIPHY_TXQ_PARAMS
+#define NL80211_ATTR_WIPHY_AP_PS_CHALLENGED NL80211_ATTR_WIPHY_AP_PS_CHALLENGED

 #define NL80211_MAX_SUPP_RATES			32
 #define NL80211_MAX_SUPP_REG_RULES		32
diff --git a/include/net/wireless.h b/include/net/wireless.h
index aedefa5..c7ec68b 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -198,6 +198,8 @@ struct wiphy {
 	u16 interface_modes;

 	bool fw_handles_regulatory;
+	/* enable AP (master mode) when the AP is without proper power saving mode */
+	bool ap_ps_challenged;

 	/* If multiple wiphys are registered and you're handed e.g.
 	 * a regular netdev with assigned ieee80211_ptr, you won't
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 00121ce..73098fe 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -149,6 +149,8 @@ static int nl80211_send_wiphy(struct sk_buff *msg,
u32 pid, u32 seq, int flags,
 	}

 	nla_nest_end(msg, nl_modes);
+	if (dev->wiphy.ap_ps_challenged)
+	    NLA_PUT_FLAG(msg, NL80211_ATTR_WIPHY_AP_PS_CHALLENGED);

 	nl_bands = nla_nest_start(msg, NL80211_ATTR_WIPHY_BANDS);
 	if (!nl_bands)

Re: [PATCH 1/2] mac80211: enabling an AP that can't support fully PS clients (wireless-testing).

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]

On Mon, 2008-11-24 at 09:44 +0200, Rami Rosen wrote:
> This patch enables mac80211 to support the PS challenged mode when
> used in master mode.
> A new attribute, NL80211_ATTR_WIPHY_AP_PS_CHALLENGED, was added to
> nl80211_attrs; also a new member (ap_ps_challenged) was added to
> struct wiphy; and nl80211_send_wiphy() was adjusted accordingly.
> 
> User space applications (like hostapd) should check the
> NL80211_ATTR_WIPHY_AP_PS_CHALLENGED
> attribute and  display a proper message, if it is set, to inform the
> users.

Jouni, thoughts about the naming? I proposed this to Rami but I'm not
married to it, any better idea?

> Signed-off-by: Rami Rosen <ramirose@gmail.com>
> 
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index 7982734..dbe15e0 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -256,6 +256,9 @@ enum nl80211_commands {
>   *	supported interface types, each a flag attribute with the number
>   *	of the interface mode.
>   *
> + * @NL80211_ATTR_WIPHY_AP_PS_CHALLENGED: indicates that the wiphy support
> + *  for PS is not full.
> + *
>   * @NL80211_ATTR_MAX: highest attribute number currently defined
>   * @__NL80211_ATTR_AFTER_LAST: internal use
>   */
> @@ -316,6 +319,8 @@ enum nl80211_attrs {
> 
>  	NL80211_ATTR_WIPHY_TXQ_PARAMS,
> 
> +	NL80211_ATTR_WIPHY_AP_PS_CHALLENGED,
> +
>  	/* add attributes here, update the policy in nl80211.c */
> 
>  	__NL80211_ATTR_AFTER_LAST,
> @@ -329,6 +334,7 @@ enum nl80211_attrs {
>  #define NL80211_ATTR_HT_CAPABILITY NL80211_ATTR_HT_CAPABILITY
>  #define NL80211_ATTR_BSS_BASIC_RATES NL80211_ATTR_BSS_BASIC_RATES
>  #define NL80211_ATTR_WIPHY_TXQ_PARAMS NL80211_ATTR_WIPHY_TXQ_PARAMS
> +#define NL80211_ATTR_WIPHY_AP_PS_CHALLENGED NL80211_ATTR_WIPHY_AP_PS_CHALLENGED
> 
>  #define NL80211_MAX_SUPP_RATES			32
>  #define NL80211_MAX_SUPP_REG_RULES		32
> diff --git a/include/net/wireless.h b/include/net/wireless.h
> index aedefa5..c7ec68b 100644
> --- a/include/net/wireless.h
> +++ b/include/net/wireless.h
> @@ -198,6 +198,8 @@ struct wiphy {
>  	u16 interface_modes;
> 
>  	bool fw_handles_regulatory;
> +	/* enable AP (master mode) when the AP is without proper power saving mode */
> +	bool ap_ps_challenged;
> 
>  	/* If multiple wiphys are registered and you're handed e.g.
>  	 * a regular netdev with assigned ieee80211_ptr, you won't
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 00121ce..73098fe 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -149,6 +149,8 @@ static int nl80211_send_wiphy(struct sk_buff *msg,
> u32 pid, u32 seq, int flags,
>  	}
> 
>  	nla_nest_end(msg, nl_modes);
> +	if (dev->wiphy.ap_ps_challenged)
> +	    NLA_PUT_FLAG(msg, NL80211_ATTR_WIPHY_AP_PS_CHALLENGED);
          ^^^^

Use tabs for indentation please.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/2] mac80211: enabling an AP that can't support fully PS clients (wireless-testing).

[John W. Linville]

On Mon, Nov 24, 2008 at 11:32:12AM +0100, Johannes Berg wrote:
> On Mon, 2008-11-24 at 09:44 +0200, Rami Rosen wrote:
> > This patch enables mac80211 to support the PS challenged mode when
> > used in master mode.
> > A new attribute, NL80211_ATTR_WIPHY_AP_PS_CHALLENGED, was added to
> > nl80211_attrs; also a new member (ap_ps_challenged) was added to
> > struct wiphy; and nl80211_send_wiphy() was adjusted accordingly.
> > 
> > User space applications (like hostapd) should check the
> > NL80211_ATTR_WIPHY_AP_PS_CHALLENGED
> > attribute and  display a proper message, if it is set, to inform the
> > users.
> 
> Jouni, thoughts about the naming? I proposed this to Rami but I'm not
> married to it, any better idea?

NL80211_ATTR_WIPHY_AP_PS_UNSUPPORTED?

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: [PATCH 1/2] mac80211: enabling an AP that can't support fully PS clients (wireless-testing).

[Pavel Roskin]

On Mon, 2008-11-24 at 09:44 +0200, Rami Rosen wrote:
> This patch enables mac80211 to support the PS challenged mode when
> used in master mode.
> A new attribute, NL80211_ATTR_WIPHY_AP_PS_CHALLENGED, was added to
> nl80211_attrs; also a new member (ap_ps_challenged) was added to
> struct wiphy; and nl80211_send_wiphy() was adjusted accordingly.
> 
> User space applications (like hostapd) should check the
> NL80211_ATTR_WIPHY_AP_PS_CHALLENGED
> attribute and  display a proper message, if it is set, to inform the
> users.

Maybe it would be better to require a switch to hostapd to enable
support for such devices?  Messages are too easy to ignore.

-- 
Regards,
Pavel Roskin

Re: [PATCH 1/2] mac80211: enabling an AP that can't support fully PS clients (wireless-testing).

[Jouni Malinen]

On Mon, Nov 24, 2008 at 03:30:12PM -0500, Pavel Roskin wrote:

> Maybe it would be better to require a switch to hostapd to enable
> support for such devices?  Messages are too easy to ignore.

Well, it would be more obvious to the user, but based on the comments on
this thread, I'm not that sure that this new flag is really needed at
this point. If the goal is to implement proper PS support in the driver,
there should not be need for this type of flag. Only if it is clear that
this won't work (i.e., hardware/firmware design issue that cannot be
fixed), should this type of flag be considered.
 
-- 
Jouni Malinen                                            PGP id EFC895FA