These patches for mac80211 and iw allow to manually set WMM parameters
(cw_min/max, AIFS, TXOP) in IBSS networks. These are only configured on
the station where this is called.
Simon Wunderlich (1):
nl80211: allow ad-hoc to set WMM parameters from outside
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
1.7.10.4
On Tue, 2012-11-27 at 19:50 +0100, Simon Wunderlich wrote:
> It can be useful to set own WMM parameters from outside, otherwise there
> is no way to change this in Ad-Hoc networks.
Having proper WMM support for IBSS doesn't seem this simple.
What about IBSS merging? What about adding WMM IEs? etc.
johannes
It can be useful to set own WMM parameters from outside, otherwise there
is no way to change this in Ad-Hoc networks.
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Mathias Kretschmer <[email protected]>
---
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c18b2fc..6d3567e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1549,7 +1549,8 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
}
if (netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
- netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO) {
+ netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO &&
+ netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_ADHOC) {
result = -EINVAL;
goto bad_res;
}
--
1.7.10.4
This is especially useful in IBSS mode.
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Mathias Kretschmer <[email protected]>
---
PATCHv2: rework parameter description in usage text
---
phy.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/phy.c b/phy.c
index 860f299..5ff127a 100644
--- a/phy.c
+++ b/phy.c
@@ -359,3 +359,80 @@ COMMAND(set, antenna, "<bitmap> | all | <tx bitmap> <rx bitmap>",
NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_antenna,
"Set a bitmap of allowed antennas to use for TX and RX.\n"
"The driver may reject antenna configurations it cannot support.");
+
+static int handle_wmm_params(struct nl80211_state *state,
+ struct nl_cb *cb,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ char *end;
+ struct nlattr *txq, *params;
+ int queue, cw_min, cw_max, aifs, txop;
+
+ if (argc != 5)
+ return 1;
+
+ if (!strcmp(argv[0], "VO"))
+ queue = NL80211_TXQ_Q_VO;
+ else if (!strcmp(argv[0], "VI"))
+ queue = NL80211_TXQ_Q_VI;
+ else if (!strcmp(argv[0], "BK"))
+ queue = NL80211_TXQ_Q_BK;
+ else if (!strcmp(argv[0], "BE"))
+ queue = NL80211_TXQ_Q_BE;
+ else {
+ printf("Invalid parameter: %s\n", argv[0]);
+ return 2;
+ }
+
+ if (!*argv[1] || !*argv[2] || !*argv[3] || !*argv[4])
+ return 1;
+
+ cw_min = strtoul(argv[1], &end, 0);
+ if (*end)
+ return 1;
+
+ cw_max = strtoul(argv[2], &end, 0);
+ if (*end)
+ return 1;
+
+ aifs = strtoul(argv[3], &end, 0);
+ if (*end)
+ return 1;
+
+ txop = strtoul(argv[4], &end, 0);
+ if (*end)
+ return 1;
+
+
+ txq = nla_nest_start(msg, NL80211_ATTR_WIPHY_TXQ_PARAMS);
+ if (!txq)
+ goto nla_put_failure;
+
+ params = nla_nest_start(msg, 1);
+ if (!params)
+ goto nla_put_failure;
+
+ NLA_PUT_U8(msg, NL80211_TXQ_ATTR_QUEUE, queue);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_CWMIN, cw_min);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_CWMAX, cw_max);
+ NLA_PUT_U8(msg, NL80211_TXQ_ATTR_AIFS, aifs);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_TXOP, txop);
+
+ nla_nest_end(msg, params);
+ nla_nest_end(msg, txq);
+
+return 0;
+
+ nla_put_failure:
+ return -ENOBUFS;
+}
+COMMAND(set, wmm_params, "<VO|VI|BE|BK> <cw_min> <cw_max> <aifs> <txop>",
+ NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_wmm_params,
+ "Set WMM parameters for a queue (VO, VI, BE, or BK):\n"
+ " * cw_min/cw_max - contention window minimum/maximum\n"
+ " (a value of the form 2^n-1 in the range 1..32767)\n"
+ " * aifs - arbitration interframe spacing (0..255)\n"
+ " * txop - maximum burst time in units of 32 usecs, 0 meaning disabled\n"
+ );
--
1.7.10.4
On Wed, Nov 28, 2012 at 03:01:35PM +0100, Johannes Berg wrote:
> On Tue, 2012-11-27 at 19:50 +0100, Simon Wunderlich wrote:
> > It can be useful to set own WMM parameters from outside, otherwise there
> > is no way to change this in Ad-Hoc networks.
>
> Having proper WMM support for IBSS doesn't seem this simple.
>
> What about IBSS merging? What about adding WMM IEs? etc.
I couldn't find anything on this in the IEEE standard - it only talks
about infrastructure mode, and that EDCA Parameter IEs should be adopted.
(Although I doubt that's a good idea).
All we want here is to locally change the parameters. Seems we are not the
first ones who want to do that [1]. The WMM specification only says that no
WMM IEs is in the beacon and distribution of parameters is missing, and
therefore defaults are to be used.
Therefore, I'd like to go for the local changes only and skip WMM IEs, adoption,
etc.
You have a point regarding IBSS merging - with this change, we would lose the
local configuration with the merge. This could be changed for mac80211,
not sure about other drivers (or if anyone actually cares).
Cheers,
Simon
[1] http://www.uniroma2.it/didattica/TPI2/deposito/wmm.pdf [page 7, bottom]
This is especially useful in IBSS mode.
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Mathias Kretschmer <[email protected]>
---
phy.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/phy.c b/phy.c
index 860f299..b4f4726 100644
--- a/phy.c
+++ b/phy.c
@@ -359,3 +359,79 @@ COMMAND(set, antenna, "<bitmap> | all | <tx bitmap> <rx bitmap>",
NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_antenna,
"Set a bitmap of allowed antennas to use for TX and RX.\n"
"The driver may reject antenna configurations it cannot support.");
+
+static int handle_wmm_params(struct nl80211_state *state,
+ struct nl_cb *cb,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ char *end;
+ struct nlattr *txq, *params;
+ int queue, cw_min, cw_max, aifs, txop;
+
+ if (argc != 5)
+ return 1;
+
+ if (!strcmp(argv[0], "VO"))
+ queue = NL80211_TXQ_Q_VO;
+ else if (!strcmp(argv[0], "VI"))
+ queue = NL80211_TXQ_Q_VI;
+ else if (!strcmp(argv[0], "BK"))
+ queue = NL80211_TXQ_Q_BK;
+ else if (!strcmp(argv[0], "BE"))
+ queue = NL80211_TXQ_Q_BE;
+ else {
+ printf("Invalid parameter: %s\n", argv[0]);
+ return 2;
+ }
+
+ if (!*argv[1] || !*argv[2] || !*argv[3] || !*argv[4])
+ return 1;
+
+ cw_min = strtoul(argv[1], &end, 0);
+ if (*end)
+ return 1;
+
+ cw_max = strtoul(argv[2], &end, 0);
+ if (*end)
+ return 1;
+
+ aifs = strtoul(argv[3], &end, 0);
+ if (*end)
+ return 1;
+
+ txop = strtoul(argv[4], &end, 0);
+ if (*end)
+ return 1;
+
+
+ txq = nla_nest_start(msg, NL80211_ATTR_WIPHY_TXQ_PARAMS);
+ if (!txq)
+ goto nla_put_failure;
+
+ params = nla_nest_start(msg, 1);
+ if (!params)
+ goto nla_put_failure;
+
+ NLA_PUT_U8(msg, NL80211_TXQ_ATTR_QUEUE, queue);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_CWMIN, cw_min);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_CWMAX, cw_max);
+ NLA_PUT_U8(msg, NL80211_TXQ_ATTR_AIFS, aifs);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_TXOP, txop);
+
+ nla_nest_end(msg, params);
+ nla_nest_end(msg, txq);
+
+return 0;
+
+ nla_put_failure:
+ return -ENOBUFS;
+}
+COMMAND(set, wmm_params, "<VO|VI|BE|BK> <cw_min> <cw_max> <aifs> <txop>",
+ NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_wmm_params,
+ "Set WMM parameters for a queue (VO, VI, BE, or BK):\n"
+ " * cw_min/cw_max - contention window min/max (miliseconds)\n"
+ " * aifs - interframe spacing (ms)\n"
+ " * txop - time for tx operation limit (in units of 32 microseconds), 0 = off\n"
+ );
--
1.7.10.4
On Fri, Dec 28, 2012 at 04:05:02PM +0100, Johannes Berg wrote:
> On Fri, 2012-11-30 at 14:43 +0100, Simon Wunderlich wrote:
> > On Wed, Nov 28, 2012 at 03:01:35PM +0100, Johannes Berg wrote:
> > > On Tue, 2012-11-27 at 19:50 +0100, Simon Wunderlich wrote:
> > > > It can be useful to set own WMM parameters from outside, otherwise there
> > > > is no way to change this in Ad-Hoc networks.
> > >
> > > Having proper WMM support for IBSS doesn't seem this simple.
> > >
> > > What about IBSS merging? What about adding WMM IEs? etc.
> >
> > I couldn't find anything on this in the IEEE standard - it only talks
> > about infrastructure mode, and that EDCA Parameter IEs should be adopted.
> > (Although I doubt that's a good idea).
>
> In infrastructure mode the values are adopted, the IEs aren't ever
> transmitted by a client...
>
> I would argue that in order to join an IBSS you need to execute the
> MLME-JOIN primitive, and that has no EDCA parameter set argument so you
> should take the values from the IBSS.
>
> Why would that be a bad idea? It seems like a much worse idea to have
> different stations in an IBSS that have different EDCA parameters.
>
The idea here is to use the standard EDCA parameters (as now), but allow local
changes. When something is adopted, it might override our local changes, and this
is what we don't want.
In our special case (mesh networks, etc) we have control over our nodes and want
to set values locally - usually the same values on all nodes (different from
standard parameters), but sometimes even different parameters, e.g. to prioritize
nodes over others. The second one is more a wishlist item, however. :)
Granted, this feature will probably not be used even by the IBSS users, but
can be useful to research and special applications and shouldn't hurt to have. :)
> > All we want here is to locally change the parameters. Seems we are not the
> > first ones who want to do that [1]. The WMM specification only says that no
> > WMM IEs is in the beacon and distribution of parameters is missing, and
> > therefore defaults are to be used.
> >
> > Therefore, I'd like to go for the local changes only and skip WMM IEs, adoption,
> > etc.
> >
> > You have a point regarding IBSS merging - with this change, we would lose the
> > local configuration with the merge. This could be changed for mac80211,
> > not sure about other drivers (or if anyone actually cares).
>
> Wait I'm lost -- you say you don't want to adopt the parameters from
> others but then when merging ...??
Right now, when merging __ieee80211_sta_join_ibss() is called which resets the
parameters back to the EDCA defaults. We would like to keep it our local parameters.
>
> It seems to me that the WMM IEs also need to be present to even tell the
> peers that you're QoS capable to start with, otherwise they'll never be
> able to use QoS towards you. You're not making all that much sense right
> now, but maybe that's because I haven't looked at the code?
Just checked again ... we already use WMM IEs in IBSS, but currently don't advertise
any EDCA parameters in them (there are appearently different WME subtypes, and only
the WME subtype==1 used by AP includes EDCA parameters). So yes, I was wrong
- we do have WMM IEs in IBSS, we use them to recognize that the peer is QoS capable.
Anyway, how can we move forward? Ways to go I see:
1.) Use local values, don't advertise the, don't adopt anything. That is basically
what the current patch does. As I said, we might lose the local changes when
merging, so this would have to be changed.
2.) Advertise EDCA parameters in WMM IEs, adopt them, and sync them with the
other IBSS nodes.
3.) Skip the patchset altogether/keep it locally, as WMM parameters should
not be changed at all (even if technically possible)
Preferences? Anyone else interested in IBSS + WMM?
Cheers,
Simon
On Fri, 2012-11-30 at 14:43 +0100, Simon Wunderlich wrote:
> On Wed, Nov 28, 2012 at 03:01:35PM +0100, Johannes Berg wrote:
> > On Tue, 2012-11-27 at 19:50 +0100, Simon Wunderlich wrote:
> > > It can be useful to set own WMM parameters from outside, otherwise there
> > > is no way to change this in Ad-Hoc networks.
> >
> > Having proper WMM support for IBSS doesn't seem this simple.
> >
> > What about IBSS merging? What about adding WMM IEs? etc.
>
> I couldn't find anything on this in the IEEE standard - it only talks
> about infrastructure mode, and that EDCA Parameter IEs should be adopted.
> (Although I doubt that's a good idea).
In infrastructure mode the values are adopted, the IEs aren't ever
transmitted by a client...
I would argue that in order to join an IBSS you need to execute the
MLME-JOIN primitive, and that has no EDCA parameter set argument so you
should take the values from the IBSS.
Why would that be a bad idea? It seems like a much worse idea to have
different stations in an IBSS that have different EDCA parameters.
> All we want here is to locally change the parameters. Seems we are not the
> first ones who want to do that [1]. The WMM specification only says that no
> WMM IEs is in the beacon and distribution of parameters is missing, and
> therefore defaults are to be used.
>
> Therefore, I'd like to go for the local changes only and skip WMM IEs, adoption,
> etc.
>
> You have a point regarding IBSS merging - with this change, we would lose the
> local configuration with the merge. This could be changed for mac80211,
> not sure about other drivers (or if anyone actually cares).
Wait I'm lost -- you say you don't want to adopt the parameters from
others but then when merging ...??
It seems to me that the WMM IEs also need to be present to even tell the
peers that you're QoS capable to start with, otherwise they'll never be
able to use QoS towards you. You're not making all that much sense right
now, but maybe that's because I haven't looked at the code?
johannes
On Wednesday 02 January 2013 13:58:19 Johannes Berg wrote:
> On Tue, 2013-01-01 at 15:46 -0800, Adrian Chadd wrote:
> > I've been looking at WME parameter handling for FreeBSD's net80211
> > stack (with and without 802.11n support.)
> >
> > Yes, the problem is figuring out what the actual BSS configuration
> > _should_ be. You could potentially hear a variety of different WMM
> > parameters from a variety of different nodes in the BSS (depending
> > upon how buggy their WMM IE handling in adhoc mode is, I guess) so you
> > can't just simply update the WMM parameters based on what you hear
> > from peers.
> >
> > What I have thus far:
> >
> > * When creating a BSS, used the stored values;
> > * When joining a BSS, use the configuration from the BSS node you've
> > initially decided to "join" against, and hope they're actually
> > "correct";
> > * When doing a BSS merge, use the configuration from the BSS node that
> > you're joining to;
> > * If a different BSS configuration is heard from the node you joined
> > against, update your local configuration;
> > * .. and set a timer that enforces you don't change your configuration
> > for another 'n' ms (for n > 1000?) even if the joined/merged BSS ID
> > changes its config.
> >
> > STA mode operation has the STA listening to changes in the BSS. It
> > only hears these frames from the active AP so you don't have churn if
> > you hear different WMM IEs from different APs (in the same SSID.)
> > adhoc is slightly crazier there.
> >
> > My only concern is having oscillating BSS updates propagate across the
> > network in a rather silly looking fashion. Hence the BGP 'route
> > dampening' style timer to try and ensure that doesn't occur.
> >
> > It'd be nice if we could come up with a unified way of doing this and
> > have it interoperate between FreeBSD/Linux (and any other vendor
> > adhoc+wmm implementations out there.)
>
> Makes sense to me, but I'm not really into IBSS.
>
> Overall, that speaks for having the parameters given as part of the
> "IBSS join" command rather than being updated on the fly though.
>
How does MESH handle these pesky WMM parameters?
I can't find anything useful in the 802.11-2012 spec either. There's
something vague in 4.7 "Difference between ESS and IBSS LANs" on page 80:
"The services that apply to an IBSS are the SSs [Station ServiceS]. [...].
The parameters that control differentiation of the delivery of MSDUs with
different priority using EDCA are >FIXED<. [...]".
But what does this mean? Does it translate into: "Every peer of an IBSS
truly independent of each other when it comes to the WMM parameters.
Each peer can advertise (in beacons, probes, ...) and have its own set
of fixed parameters and no one needs to sync those from anyone else"?
Or does "fixed" just mean that everyone has to go with the default WMM
parameters from 8-105 [i.e.: no one can change them at all]?
Regards,
Christian
On Wed, Jan 02, 2013 at 03:41:28PM +0100, Johannes Berg wrote:
> On Wed, 2013-01-02 at 14:36 +0100, Christian Lamparter wrote:
>
> > I can't find anything useful in the 802.11-2012 spec either. There's
> > something vague in 4.7 "Difference between ESS and IBSS LANs" on page 80:
> > "The services that apply to an IBSS are the SSs [Station ServiceS]. [...].
> > The parameters that control differentiation of the delivery of MSDUs with
> > different priority using EDCA are >FIXED<. [...]".
> >
> > But what does this mean? Does it translate into: "Every peer of an IBSS
> > truly independent of each other when it comes to the WMM parameters.
> > Each peer can advertise (in beacons, probes, ...) and have its own set
> > of fixed parameters and no one needs to sync those from anyone else"?
> >
> > Or does "fixed" just mean that everyone has to go with the default WMM
> > parameters from 8-105 [i.e.: no one can change them at all]?
>
> Yeah it's a little vague, but I think it means *fixed* as you describe.
> The WMM spec describes them as fixed and also doesn't include the WMM
> Parameter IE in beacons/probe responses, so all of this would be an
> extension to the spec and we have to be careful not to break the spec
> (default) case (which is correct right now, afaict, with default
> parameters and no parameters IE)
It appears that WMM IEs never carry EDCA parameters, and this is also not
specified anywhere that IBSS-stations should do that. All I can find is to use
the default EDCA parameters, and this is done right now in Linux - external WMM
IEs are ignored.
For the original patch, I'd still opt to have it integrated:
* if no WMM EDCA parameters are provided from userspace, the default behaviour
is still to use the default EDCA parameters - 99% of the people won't change
that
* changed parameter sets don't have to be exposed to other nodes - the BSS
won't break if nodes will have other parameters, it might just behave
unexpected in terms of priority. Normal users won't tamper with EDCA parameters
and shouldn't notice that at all.
* Exposing EDCA parameters in the WMM IEs is technically possible, but will
probably give us more headache (syncing them, most clients won't support that,
etc) then solve problems.
With the current patch, one can just set the parameters locally, using the
already existing nl80211-commands for AP. One thing we still need to consider
is the ibss-merge case (mac80211 will reset to EDCA defaults then, we want
to keep the custom values). I can provide a patch for that, of course.
>
> Interoperating with FreeBSD would be useful though.
Yeah I agree. Don't know what the state in FreeBSD is now, but I'd still suggest
to not use EDCA-parameters in WMM IEs for reasons above. Even if Linux and FreeBSD
supports it in their open source drivers, there will probably tons of other drivers
not supporting these parameters and breaking the mechanism - this is not standard
behaviour, after all.
Adrian, others, what do you think?
Cheers,
Simon
On Tue, 2013-01-01 at 15:46 -0800, Adrian Chadd wrote:
> I've been looking at WME parameter handling for FreeBSD's net80211
> stack (with and without 802.11n support.)
>
> Yes, the problem is figuring out what the actual BSS configuration
> _should_ be. You could potentially hear a variety of different WMM
> parameters from a variety of different nodes in the BSS (depending
> upon how buggy their WMM IE handling in adhoc mode is, I guess) so you
> can't just simply update the WMM parameters based on what you hear
> from peers.
>
> What I have thus far:
>
> * When creating a BSS, used the stored values;
> * When joining a BSS, use the configuration from the BSS node you've
> initially decided to "join" against, and hope they're actually
> "correct";
> * When doing a BSS merge, use the configuration from the BSS node that
> you're joining to;
> * If a different BSS configuration is heard from the node you joined
> against, update your local configuration;
> * .. and set a timer that enforces you don't change your configuration
> for another 'n' ms (for n > 1000?) even if the joined/merged BSS ID
> changes its config.
>
> STA mode operation has the STA listening to changes in the BSS. It
> only hears these frames from the active AP so you don't have churn if
> you hear different WMM IEs from different APs (in the same SSID.)
> adhoc is slightly crazier there.
>
> My only concern is having oscillating BSS updates propagate across the
> network in a rather silly looking fashion. Hence the BGP 'route
> dampening' style timer to try and ensure that doesn't occur.
>
> It'd be nice if we could come up with a unified way of doing this and
> have it interoperate between FreeBSD/Linux (and any other vendor
> adhoc+wmm implementations out there.)
Makes sense to me, but I'm not really into IBSS.
Overall, that speaks for having the parameters given as part of the
"IBSS join" command rather than being updated on the fly though.
johannes
I've been looking at WME parameter handling for FreeBSD's net80211
stack (with and without 802.11n support.)
Yes, the problem is figuring out what the actual BSS configuration
_should_ be. You could potentially hear a variety of different WMM
parameters from a variety of different nodes in the BSS (depending
upon how buggy their WMM IE handling in adhoc mode is, I guess) so you
can't just simply update the WMM parameters based on what you hear
from peers.
What I have thus far:
* When creating a BSS, used the stored values;
* When joining a BSS, use the configuration from the BSS node you've
initially decided to "join" against, and hope they're actually
"correct";
* When doing a BSS merge, use the configuration from the BSS node that
you're joining to;
* If a different BSS configuration is heard from the node you joined
against, update your local configuration;
* .. and set a timer that enforces you don't change your configuration
for another 'n' ms (for n > 1000?) even if the joined/merged BSS ID
changes its config.
STA mode operation has the STA listening to changes in the BSS. It
only hears these frames from the active AP so you don't have churn if
you hear different WMM IEs from different APs (in the same SSID.)
adhoc is slightly crazier there.
My only concern is having oscillating BSS updates propagate across the
network in a rather silly looking fashion. Hence the BGP 'route
dampening' style timer to try and ensure that doesn't occur.
It'd be nice if we could come up with a unified way of doing this and
have it interoperate between FreeBSD/Linux (and any other vendor
adhoc+wmm implementations out there.)
Thanks,
Adrian
On Wed, 2013-01-02 at 14:36 +0100, Christian Lamparter wrote:
> I can't find anything useful in the 802.11-2012 spec either. There's
> something vague in 4.7 "Difference between ESS and IBSS LANs" on page 80:
> "The services that apply to an IBSS are the SSs [Station ServiceS]. [...].
> The parameters that control differentiation of the delivery of MSDUs with
> different priority using EDCA are >FIXED<. [...]".
>
> But what does this mean? Does it translate into: "Every peer of an IBSS
> truly independent of each other when it comes to the WMM parameters.
> Each peer can advertise (in beacons, probes, ...) and have its own set
> of fixed parameters and no one needs to sync those from anyone else"?
>
> Or does "fixed" just mean that everyone has to go with the default WMM
> parameters from 8-105 [i.e.: no one can change them at all]?
Yeah it's a little vague, but I think it means *fixed* as you describe.
The WMM spec describes them as fixed and also doesn't include the WMM
Parameter IE in beacons/probe responses, so all of this would be an
extension to the spec and we have to be careful not to break the spec
(default) case (which is correct right now, afaict, with default
parameters and no parameters IE)
Interoperating with FreeBSD would be useful though.
johannes
I still populate the WME fields; I need to "fix" paying attention to
them in the adhoc case.
The performance loss without them is quite noticable.
Adrian
Hello Simon,
On Wednesday, January 09, 2013 03:33:04 PM Simon Wunderlich wrote:
> On Wed, Jan 09, 2013 at 03:10:49PM +0100, Christian Lamparter wrote:
> > On Wednesday, January 09, 2013 02:15:40 PM Simon Wunderlich wrote:
> > > On Tue, Jan 08, 2013 at 09:28:44AM -0800, Adrian Chadd wrote:
> > > > I still populate the WME fields; I need to "fix" paying attention to
> > > > them in the adhoc case.
> > >
> > > Applying the EDCA parameters in the hardware and sending "standard" WME IEs
> > > (without EDCA parameter sets) is understandable, Linux does that too.
> >
> > Well, the WFA WMM Specification v1.2 costs $99 (last time I checked, which wasn't
> > too long ago). However Johannes told me that the WMM IE should not be added
> > to IBSS beacons.
>
> I don't have the spec, and I don't intend to buy it. :)
>
> But: We do have WMM IE sent by Linux IBSS STAs even today.
Ah, but I think you shouldn't ;).
> The difference to the AP WMM IEs is that it doesn't include EDCA parameters
> (cwmin/max, aifs, ...). But still, this is useful to detect that the other
> IBBS station is WMM-capable: we can then use QOS_DATA frames, use noack, etc ...
There's also the QoS Capability IE (8.4.2.37). It needs 3 bytes (one for the IE
ID, one for an IE LEN and then the QoS cap byte). But of course, the spec
doesn't say how it should be parsed for the IBSS case.
Regards,
Chr
On Wednesday, January 09, 2013 02:15:40 PM Simon Wunderlich wrote:
> On Tue, Jan 08, 2013 at 09:28:44AM -0800, Adrian Chadd wrote:
> > I still populate the WME fields; I need to "fix" paying attention to
> > them in the adhoc case.
>
> Applying the EDCA parameters in the hardware and sending "standard" WME IEs
> (without EDCA parameter sets) is understandable, Linux does that too.
Well, the WFA WMM Specification v1.2 costs $99 (last time I checked, which wasn't
too long ago). However Johannes told me that the WMM IE should not be added
to IBSS beacons.
However, we can still pack some EDCA parameters into beacons, probe/(re-)assoc
resps because there's an alternative IE. The "EDCA Parameter Set IE" is part of
802.11-2012 8.4.2.31 - The Element ID is 12 [Table 8-54].
[Note: It's worth mentioning that the WFA WMM spec was just a stop-gap measure
until 802.11e was ready. Here's an article which explains this weird bit of
history, unfortunately it is in German
<http://www.heise.de/netze/artikel/Parallelnorm-WMM-223736.html>]
Regards,
Chr
Hello Christian,
On Wed, Jan 09, 2013 at 03:10:49PM +0100, Christian Lamparter wrote:
> On Wednesday, January 09, 2013 02:15:40 PM Simon Wunderlich wrote:
> > On Tue, Jan 08, 2013 at 09:28:44AM -0800, Adrian Chadd wrote:
> > > I still populate the WME fields; I need to "fix" paying attention to
> > > them in the adhoc case.
> >
> > Applying the EDCA parameters in the hardware and sending "standard" WME IEs
> > (without EDCA parameter sets) is understandable, Linux does that too.
>
> Well, the WFA WMM Specification v1.2 costs $99 (last time I checked, which wasn't
> too long ago). However Johannes told me that the WMM IE should not be added
> to IBSS beacons.
I don't have the spec, and I don't intend to buy it. :)
But: We do have WMM IE sent by Linux IBSS STAs even today. The difference to the AP
WMM IEs is that it doesn't include EDCA parameters (cwmin/max, aifs, ...). But still,
this is useful to detect that the other IBBS station is WMM-capable: we can then
use QOS_DATA frames, use noack, etc ...
>
> However, we can still pack some EDCA parameters into beacons, probe/(re-)assoc
> resps because there's an alternative IE. The "EDCA Parameter Set IE" is part of
> 802.11-2012 8.4.2.31 - The Element ID is 12 [Table 8-54].
Ah didn't know that - thanks for pointing that out. Although I'm still in favor of
not sending anything in IBSS and do local changes only. :)
>
> [Note: It's worth mentioning that the WFA WMM spec was just a stop-gap measure
> until 802.11e was ready. Here's an article which explains this weird bit of
> history, unfortunately it is in German
> <http://www.heise.de/netze/artikel/Parallelnorm-WMM-223736.html>]
>
> Regards,
> Chr
On Tue, Jan 08, 2013 at 09:28:44AM -0800, Adrian Chadd wrote:
> I still populate the WME fields; I need to "fix" paying attention to
> them in the adhoc case.
Applying the EDCA parameters in the hardware and sending "standard" WME IEs
(without EDCA parameter sets) is understandable, Linux does that too.
But are you really sending EDCA parameters in IBSS mode within the WME IEs?
After all, STAs in infrastructure don't do this either.
>
> The performance loss without them is quite noticable.
I don't understand why. If you apply the default EDCA parameters/QoS parameters
in the hardware, it shouldn't make a difference if you transmit EDCA parameters
in your beacons or not. I'm confused. :)
Cheers,
Simon