Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Markus Theil <markus.theil@tu-ilmenau.de>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] nl80211: allow more operations for mesh and ad-hoc interfaces
Date: Wed, 30 Oct 2019 15:04:48 +0100	[thread overview]
Message-ID: <48aa046256186ecc3aaffb9c6642ab44ae91bbd4.camel@sipsolutions.net> (raw)
In-Reply-To: <f9828fb2-eda9-5e05-7683-0c180e994f43@tu-ilmenau.de>

On Wed, 2019-10-30 at 14:40 +0100, Markus Theil wrote:
> 
> Mesh interfaces are allowed to perform EDCA according to the standard
> 802.11-2016.

Well, they *have to* in a sense :-)

[...]
> 
> Changing beacons on the fly from user-space in these modes is only
> useful, if vendor-specific elements are used, which can change over time.
> 
> All in all I can nevertheless understand your point, that these changes
> could be "wrong" from a pragmatic point of view.

No no, that's not even it. The problem is that you're focusing too much
on the standard without understanding how the stack works.

Take the QoS parameters again for example. Setting them from userspace
is wrong because that data will immediately be forgotten and killed
again by the call to ieee80211_set_wmm_default() in that code.

Or look at how the change_beacon call is handled - the data you set here
will never even be used for IBSS or mesh because in mac80211
ieee80211_change_beacon() will quite possibly even crash when you call
it for a non-AP interface since it accesses sdata->u.ap.beacon without
any other checks.

So while the *idea* of being able to change beacons or WMM parameters
*might* be correct, this kind of implementation is (fairly obviously)
completely wrong.

johannes


  reply	other threads:[~2019-10-30 14:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 11:56 [PATCH] nl80211: allow more operations for mesh and ad-hoc interfaces Markus Theil
2019-10-30  9:03 ` Johannes Berg
2019-10-30 13:40   ` Markus Theil
2019-10-30 14:04     ` Johannes Berg [this message]
2019-10-30 14:10       ` Markus Theil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48aa046256186ecc3aaffb9c6642ab44ae91bbd4.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=markus.theil@tu-ilmenau.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox