Linux-Wireless Archive mirror
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Stefan Schmidt <stefan@datenfreihafen.org>,
	linux-wpan - ML <linux-wpan@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	"open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
	Michael Hennerich <michael.hennerich@analog.com>,
	Harry Morris <h.morris@cascoda.com>,
	Varka Bhadram <varkabhadram@gmail.com>,
	Xue Liu <liuxuenetmail@gmail.com>, Alan Ott <alan@signal11.us>,
	David Girault <david.girault@qorvo.com>,
	Romuald Despres <romuald.despres@qorvo.com>,
	Frederic Blain <frederic.blain@qorvo.com>,
	Nicolas Schodet <nico@ni.fr.eu.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	"linux-wireless@vger.kernel.org Wireless" 
	<linux-wireless@vger.kernel.org>
Subject: Re: [wpan-next v2 08/27] net: ieee802154: Drop symbol duration settings when the core does it already
Date: Wed, 19 Jan 2022 18:26:15 -0500	[thread overview]
Message-ID: <CAB_54W6AeRY5cP1KpaUH1VsCWtafdvPXkubPwq8rrDw-Vg4hvg@mail.gmail.com> (raw)
In-Reply-To: <20220119232600.6b8755d0@xps13>

Hi,

On Wed, 19 Jan 2022 at 17:26, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@gmail.com wrote on Tue, 18 Jan 2022 17:43:00 -0500:
>
> > Hi,
> >
> > On Tue, 18 Jan 2022 at 05:38, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Alexander,
> > >
> > > > > > btw:
> > > > > > Also for testing with hwsim and the missing features which currently
> > > > > > exist. Can we implement some user space test program which replies
> > > > > > (active scan) or sends periodically something out via AF_PACKET raw
> > > > > > and a monitor interface that should work to test if it is working?
> > > > >
> > > > > We already have all this handled, no need for extra software. You can
> > > > > test active and passive scans between two hwsim devices already:
> > > > >
> > > > > # iwpan dev wpan0 beacons send interval 15
> > > > > # iwpan dev wpan1 scan type active duration 1
> > > > > # iwpan dev wpan0 beacons stop
> > > > >
> > > > > or
> > > > >
> > > > > # iwpan dev wpan0 beacons send interval 1
> > > > > # iwpan dev wpan1 scan type passive duration 2
> > > > > # iwpan dev wpan0 beacons stop
> > > > >
> > > > > > Ideally we could do that very easily with scapy (not sure about their
> > > > > > _upstream_ 802.15.4 support). I hope I got that right that there is
> > > > > > still something missing but we could fake it in such a way (just for
> > > > > > hwsim testing).
> > > > >
> > > > > I hope the above will match your expectations.
> > > > >
> > > >
> > > > I need to think and read more about... in my mind is currently the
> > > > following question: are not coordinators broadcasting that information
> > > > only? Means, isn't that a job for a coordinator?
> > >
> > > My understanding right now:
> > > - The spec states that coordinators only can send beacons and perform
> > >   scans.
> >
> > ok.
> >
> > > - I don't yet have the necessary infrastructure to give coordinators
> > >   more rights than regular devices or RFDs (but 40+ patches already,
> > >   don't worry this is something we have in mind)
> > > - Right now this is the user to decide whether a device might answer
> > >   beacon requests or not. This will soon become more limited but it
> > >   greatly simplifies the logic for now.
> > >
> >
> > There was always the idea behind it to make an "coordinator" interface
> > type and there is a reason for that because things e.g. filtering
> > becomes different than a non-coordinator interface type (known as node
> > interface in wpan).
> > At the end interface types should make a big difference in how the
> > "role" inside the network should be, which you can also see in
> > wireless as "station"/"access point" interface devices.
> >
> > A non full functional device should then also not be able to act as a
> > coordinator e.g. it cannot create coordinator types.
>
> I've added a few more parameters to be able to reflect the type of
> device (ffd, rfd, rfd_r/tx) and also eventually its coordinator state.
> I've hacked into nl802154 to give these information to the user and let
> it device wether the device (if it's an ffd) should act as a
> coordinator. This is only a first step before we create a real PAN
> creation procedure of course.
>
> I've then adapted the following patches to follow check against the
> device/coordinator state to decide if an operation should be aborted or
> not.

Okay, I need to see the patches to say anything about that and how it fits.

The problem still exists that we don't currently have any distinction
to know if a device can do it or not. After this patch series every
"node interface" is allowed to scan/send beacons, where a node
interface should not be allowed to do it. If we change it later we
break things. However there is still the question if we care about it
because 802.15.4 is in such an early/experimental state. It was
"experimental" as the Kconfig EXPERIMENTAL entry still existed. It was
dropped because most people ignored this setting, that doesn't mean
that 802.15.4 ever left the experimental state.

- Alex

  reply	other threads:[~2022-01-19 23:26 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 17:32 [wpan-next v2 00/27] IEEE 802.15.4 scan support Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 01/27] net: mac802154: Split the set channel hook implementation Miquel Raynal
2022-01-12 22:30   ` Alexander Aring
2022-01-12 22:53     ` Alexander Aring
2022-01-13 11:12       ` Miquel Raynal
2022-01-13  9:32     ` Miquel Raynal
2022-01-13 23:27       ` Alexander Aring
2022-01-12 17:32 ` [wpan-next v2 02/27] net: mac802154: Ensure proper channel selection at probe time Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 03/27] net: ieee802154: Improve the way supported channels are declared Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 04/27] net: ieee802154: Give more details to the core about the channel configurations Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 05/27] net: mac802154: Convert the symbol duration into nanoseconds Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 06/27] net: mac802154: Set the symbol duration automatically Miquel Raynal
2022-01-12 22:25   ` Alexander Aring
2022-01-13  9:52     ` Miquel Raynal
2022-01-13 23:36   ` Alexander Aring
2022-01-14 10:18     ` Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 07/27] net: ieee802154: hwsim: Ensure frame checksum are valid Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 08/27] net: ieee802154: Drop symbol duration settings when the core does it already Miquel Raynal
2022-01-12 22:26   ` Alexander Aring
2022-01-13 11:16     ` Miquel Raynal
2022-01-13 23:34       ` Alexander Aring
2022-01-14 10:21         ` Miquel Raynal
2022-01-16 23:21           ` Alexander Aring
2022-01-17  9:12             ` Miquel Raynal
2022-01-17 23:38               ` Alexander Aring
2022-01-18 10:38                 ` Miquel Raynal
2022-01-18 22:43                   ` Alexander Aring
2022-01-19 22:26                     ` Miquel Raynal
2022-01-19 23:26                       ` Alexander Aring [this message]
2022-01-12 17:32 ` [wpan-next v2 09/27] net: ieee802154: Move IEEE 802.15.4 Kconfig main entry Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 10/27] net: mac802154: Include the softMAC stack inside the IEEE 802.15.4 menu Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 11/27] net: ieee802154: Move the address structure earlier Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 12/27] net: ieee802154: Add a kernel doc header to the ieee802154_addr structure Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 13/27] net: ieee802154: Return meaningful error codes from the netlink helpers Miquel Raynal
2022-01-12 17:32 ` [wpan-next v2 14/27] net: ieee802154: Add support for internal PAN management Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 15/27] net: ieee802154: Define a beacon frame header Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 16/27] net: ieee802154: Define frame types Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 17/27] net: ieee802154: Add support for scanning requests Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 18/27] net: mac802154: Handle scan requests Miquel Raynal
2022-01-12 22:44   ` Alexander Aring
2022-01-13 17:07     ` Miquel Raynal
2022-01-14  0:01       ` Alexander Aring
2022-01-14 18:44         ` Miquel Raynal
2022-01-16 22:44           ` Alexander Aring
2022-01-16 22:50             ` Alexander Aring
2022-01-17  9:00             ` Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 19/27] net: ieee802154: Full PAN management Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 20/27] net: ieee802154: Add support for beacon requests Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 21/27] net: mac802154: Handle beacons requests Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 22/27] net: ieee802154: Trace the registration of new PANs Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 23/27] net: mac802154: Add support for active scans Miquel Raynal
2022-01-12 23:16   ` Alexander Aring
2022-01-13 17:14     ` Miquel Raynal
2022-01-14  0:30       ` Alexander Aring
2022-01-14  0:39         ` Alexander Aring
2022-01-12 17:33 ` [wpan-next v2 24/27] net: mac802154: Add support for processing beacon requests Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 25/27] net: mac802154: Inform device drivers about scans Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 26/27] net: mac802154: Inform device drivers about beacon operations Miquel Raynal
2022-01-12 17:33 ` [wpan-next v2 27/27] net: ieee802154: ca8210: Refuse most of the scan operations Miquel Raynal
2022-01-12 22:48   ` Alexander Aring
2022-01-13  9:29     ` Miquel Raynal
2022-01-14  1:00       ` Alexander Aring
2022-01-14 18:37         ` Miquel Raynal
2022-01-16 22:48           ` Alexander Aring
2022-01-17  9:04             ` Miquel Raynal

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=CAB_54W6AeRY5cP1KpaUH1VsCWtafdvPXkubPwq8rrDw-Vg4hvg@mail.gmail.com \
    --to=alex.aring@gmail.com \
    --cc=alan@signal11.us \
    --cc=davem@davemloft.net \
    --cc=david.girault@qorvo.com \
    --cc=frederic.blain@qorvo.com \
    --cc=h.morris@cascoda.com \
    --cc=kuba@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=liuxuenetmail@gmail.com \
    --cc=michael.hennerich@analog.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=nico@ni.fr.eu.org \
    --cc=romuald.despres@qorvo.com \
    --cc=stefan@datenfreihafen.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=varkabhadram@gmail.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).