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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48217ECAAD2 for ; Fri, 2 Sep 2022 02:09:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233716AbiIBCJ4 (ORCPT ); Thu, 1 Sep 2022 22:09:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230313AbiIBCJy (ORCPT ); Thu, 1 Sep 2022 22:09:54 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67312EB1 for ; Thu, 1 Sep 2022 19:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662084591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Glclh5v/Wd515YHsUVu6CqjDmnWddkL3V2d3UpUAO5g=; b=isOP0sX2pA7/Q7PAOsnEyu2z9u/bdQIb0hWPAgaxDJg/3d/BLHnXkMUifYErygMEQXjCAm pwNjZec3JIVNAZkUwIqD2C6hToKSzl1cDjRmqz65w7dHHnzUWbLZSCHtyudANKceZu4Qxa bl+9fmBesTL5JXqoex00kdApuwrNgpc= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-32-6w8m8nX3PWqSpqp6-6Agtw-1; Thu, 01 Sep 2022 22:09:50 -0400 X-MC-Unique: 6w8m8nX3PWqSpqp6-6Agtw-1 Received: by mail-qv1-f72.google.com with SMTP id nv16-20020a056214361000b00499023aff0bso411445qvb.12 for ; Thu, 01 Sep 2022 19:09:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Glclh5v/Wd515YHsUVu6CqjDmnWddkL3V2d3UpUAO5g=; b=6ss4Z5BCpqDmxxyHSNxk6CjEYYy8btnjDST7Cbv1V2j9HC0+yikXL44x1pHR3YA7+k JaBLq+NkthnFiAdTQdjw5YRPnvvVl0Zud02wQpW7pZf8NauXbn6vSP76u/kFKQo92DiV BxKgTKJBw5wc9a874a/VE+fGUxv3T9CVbHnAcNrZf81Ti83llq7zaETVZ1DszAv8JA2a rwUgcswdsChAZWNqTO/U3eRCfPiFk3Zh0wHCemgg2KZ6E0i+a/Lk7dTNbIVbrk1UDhbI u8qgHzg0iO+M3k9WrBm01qEbdFFcxaZwIxYPnApQs3pJx1SWpVs15yMdWz/l5+RJolZo uNJg== X-Gm-Message-State: ACgBeo0N0lWNBejZEcogDhnzvsu1fuXstjx53LtuSTyr//nv5b+B0zoo aK3riUCZazbpVtXmojH2Iug+AyYyhLdVKyy49WovNY6xvWPbK17IFmqLy/AiZOX1eOeZ2dTmpmv +Bes1l4XUV62VdB1kHiXkatDGe285p+0FYatiyA== X-Received: by 2002:a05:622a:1302:b0:344:8a9d:817d with SMTP id v2-20020a05622a130200b003448a9d817dmr26446570qtk.339.1662084590014; Thu, 01 Sep 2022 19:09:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR4Un99Kv+7MWxTnnA6cj8sXjWtQ2lyfiPpnnHJEuN6JRm6toB3pjlq+PX8Vi1+jD4tyOJ4AWle0W/ExIHE7/3Y= X-Received: by 2002:a05:622a:1302:b0:344:8a9d:817d with SMTP id v2-20020a05622a130200b003448a9d817dmr26446557qtk.339.1662084589801; Thu, 01 Sep 2022 19:09:49 -0700 (PDT) MIME-Version: 1.0 References: <20220701143052.1267509-1-miquel.raynal@bootlin.com> <20220701143052.1267509-2-miquel.raynal@bootlin.com> <20220819191109.0e639918@xps-13> <20220823182950.1c722e13@xps-13> <20220824122058.1c46e09a@xps-13> <20220824152648.4bfb9a89@xps-13> <20220825145831.1105cb54@xps-13> <20220826095408.706438c2@xps-13> <20220829100214.3c6dad63@xps-13> <20220831173903.1a980653@xps-13> In-Reply-To: <20220831173903.1a980653@xps-13> From: Alexander Aring Date: Thu, 1 Sep 2022 22:09:38 -0400 Message-ID: Subject: Re: [PATCH wpan-next 01/20] net: mac802154: Allow the creation of coordinator interfaces To: Miquel Raynal Cc: Alexander Aring , Stefan Schmidt , linux-wpan - ML , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Network Development , David Girault , Romuald Despres , Frederic Blain , Nicolas Schodet , Thomas Petazzoni Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-wpan@vger.kernel.org Hi, On Wed, Aug 31, 2022 at 11:39 AM Miquel Raynal wrote: > > Hi Alexander & Stefan, > > aahringo@redhat.com wrote on Mon, 29 Aug 2022 22:23:09 -0400: > > I am currently testing my code with the ATUSB devices, the association > works, so it's a good news! However I am struggling to get the > association working for a simple reason: the crafted ACKs are > transmitted (the ATUSB in monitor mode sees it) but I get absolutely What is a crafted ACK here? > nothing on the receiver side. > > The logic is: > > coord0 coord1 > association req -> > <- ack > <- association response > ack -> > > The first ack is sent by coord1 but coord0 never sees anything. In > practice coord0 has sent an association request and received a single > one-byte packet in return which I guess is the firmware saying "okay, Tx > has been performed". Shall I interpret this byte differently? Does it > mean that the ack has also been received? > > I could not find a documentation of the firmware interface, I went > through the wiki but I did not find something clear about what to > expect or "what the driver should do". But perhaps this will ring a > bell on your side? > > [...] > > > I did not see the v2 until now. Sorry for that. > > Ah! Ok, no problem :) > > > > > However I think there are missing bits here at the receive handling > > side. Which are: > > > > 1. Do a stop_tx(), stop_rx(), start_rx(filtering_level) to go into > > other filtering modes while ifup. > > Who is supposed to change the filtering level? > depending on what mac802154 is doing, for scan it's required to switch the filter level to promiscuous? > For now there is only the promiscuous mode being applied and the user > has no knowledge about it, it's just something internal. > Okay, sounds good. > Changing how the promiscuous mode is applied (using a filtering level > instead of a "promiscuous on" boolean) would impact all the drivers > and for now we don't really need it. > no, it does not. Okay, you can hide the promiscuous mode driver callback from start()... but yes the goal would be to remove the promiscuous mode op in future. > > I don't want to see all filtering modes here, just what we currently > > support with NONE (then with FCS check on software if necessary), > > ?THIRD/FOURTH? LEVEL filtering and that's it. What I don't want to see > > is runtime changes of phy flags. To tell the receive path what to > > filter and what's not. > > Runtime changes on a dedicated "filtering" PHY flag is what I've used > and it works okay for this situation, why don't you want that? It > avoids the need for (yet) another rework of the API with the drivers, > no? > I am not sure what exactly here is "dedicated "filtering" PHY flag" if it's the hwflags it was never made to be changed during runtime. I also don't know what "yet another rework of the API" means here, there is a current behaviour which we can assume and only hwsim is a little bit out of range which should overwrite the "default". > > 2. set the pan coordinator bit for hw address filter. And there is a > > TODO about setting pkt_type in mac802154 receive path which we should > > take a look into. This bit should be addressed for coordinator support > > even if there is the question about coordinator vs pan coordinator, > > then the kernel needs a bit as coordinator iface type parameter to > > know if it's a pan coordinator and not coordinator. > > This is not really something that we can "set". Either the device > had performed an association and it is a child device: it is not the > PAN coordinator, or it initiated the PAN and it is the PAN coordinator. > There are commands to change that later on but those are not supported. > > The "PAN coordinator" information is being added in the association > series (which comes after the scan). I have handled the pkt_type you are > mentioning. > okay. - Alex