From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65CF0CA9EC5 for ; Wed, 30 Oct 2019 14:04:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 46A78208C0 for ; Wed, 30 Oct 2019 14:04:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726700AbfJ3OEw (ORCPT ); Wed, 30 Oct 2019 10:04:52 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:59944 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726284AbfJ3OEv (ORCPT ); Wed, 30 Oct 2019 10:04:51 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.2) (envelope-from ) id 1iPoag-0003zY-5O; Wed, 30 Oct 2019 15:04:50 +0100 Message-ID: <48aa046256186ecc3aaffb9c6642ab44ae91bbd4.camel@sipsolutions.net> Subject: Re: [PATCH] nl80211: allow more operations for mesh and ad-hoc interfaces From: Johannes Berg To: Markus Theil Cc: linux-wireless@vger.kernel.org Date: Wed, 30 Oct 2019 15:04:48 +0100 In-Reply-To: References: <20191029115602.78990-1-markus.theil@tu-ilmenau.de> <4b9c7b36f175667a76609c6560618bb48a321ed8.camel@sipsolutions.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 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