Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2505084ybg; Fri, 31 Jul 2020 01:26:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSmtRrrlkNWEIZnKBBhvZyCEaYIE4GmEdLiK2bGtlXcmEk6rrgoHHD8Ygec31emTijz674 X-Received: by 2002:a17:906:1911:: with SMTP id a17mr2706475eje.431.1596183959921; Fri, 31 Jul 2020 01:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596183959; cv=none; d=google.com; s=arc-20160816; b=W+qVLf7jk+bwlhbinLKE2AwvxLof4kLxi/37VRsQi1KTqrpTpucQr3PkjPLziAtqUT DACK0NPcewlvwzRQM7bptAoubynGNqxQlro06Y+a9FZltZUteY8dOcPtPDX4Tq1JUrMH WHFSms/+r0LaPhqmoulxtE773eK9ShVOpoZdRPSNgbT22aSnjgUE9Qg4reWm5OVsXct1 6Hbdu0tsHhAOLxa93ZPD9z3OwzVeja5C3DeB6VNkdXqPmU3EMZwMVqOTVquGYVgBUq0n R6T7uNeiq7kwBeLI4aKaE8l0hESbbBM0SXdJ335TmZyga26Sg1G5KW8sRxBR5aknyqXU VZUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=g1dwj+/U5NL2zaqd899DF2/xmnIQrGeI0tcZtr+0tB8=; b=Nnng9xzWya55rOm3jX/n9g55KfK+xoc3IoTvAENzHTDaY69aS3/l73/oEHLldjNva5 k9VTs9NU80cFrQ0bFZwo+u6/qCG3qkkGo3k/f+GvDdc0WlmMVNeIF+qm4SS/5RGLt5Hl DJFSrk/GVCRdyyxE26zJ8/AgZLdhnLJJv3BITrIt9OdQ3YPaWDGvjucnpLg3CHDPdhCA ENFY3L1D+wOMfV3tEM6PSG5iNB22WMVuQigy1rASo6OQ0VYdbVITgD+0AfUsZfOSJOtN FsKaJO1u+Z7FXlKpS6fk7CbP5SvzjlYTwBpzLsURhkgKiQ+wHakGeprS1d8zVFVT4AX9 eDmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q22si4385095ejn.410.2020.07.31.01.25.22; Fri, 31 Jul 2020 01:25:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731908AbgGaIVj (ORCPT + 99 others); Fri, 31 Jul 2020 04:21:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731905AbgGaIVj (ORCPT ); Fri, 31 Jul 2020 04:21:39 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 758D5C061574; Fri, 31 Jul 2020 01:21:39 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1k1QIL-00E0Sn-O6; Fri, 31 Jul 2020 10:21:37 +0200 Message-ID: <1005f6fa9d017241b47ec925ce0aa5432926b51c.camel@sipsolutions.net> Subject: Re: [PATCH v4 2/2] mac80211: Add FILS discovery support From: Johannes Berg To: Aloka Dixit Cc: linux-wireless@vger.kernel.org, linux-wireless-owner@vger.kernel.org Date: Fri, 31 Jul 2020 10:21:36 +0200 In-Reply-To: <78c89ff151efbdff2e579733d6b1d98c@codeaurora.org> References: <20200618050427.5891-1-alokad@codeaurora.org> <20200618050427.5891-3-alokad@codeaurora.org> <78c89ff151efbdff2e579733d6b1d98c@codeaurora.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4 (3.36.4-1.fc32) 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 Thu, 2020-07-30 at 15:08 -0700, Aloka Dixit wrote: > Min and max intervals are used to decide if a FILS discovery frame > should be sent at all when respective timers expires. > Depending on how close that time is to the next beacons, the device may > just send the beacon instead. Right, OK. > In lower bands, for non-offloaded case, FW will send events asking for > the frame until it gets one. Aha. > Whether that should go all the way to hostapd or should the driver > itself handle it remains to be seen. I don't see why it should go up - the driver can have the template and answer that? I mean, we already push the template down. > My current focus is only 6GHz, but didn't want to restrict kernel > implementation so moved 6GHz related checks to the driver instead. It might still make sense to have a bitmap of where FILS discovery is supported, if it's different for different bands? Unless of course you think that a given device will always support FILS discovery on all bands, you just haven't implemented it yet for all bands - but will complete it before really enabling it in the driver? > All in all, making the template mandatory will be safer so that the > driver will always have one if required. Agree. Thanks! johannes