lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220104164449.1179bfc7@xps13>
Date:   Tue, 4 Jan 2022 16:44:49 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [net-next 01/18] ieee802154: hwsim: Ensure proper channel
 selection at probe time

Hi Alexander,

alex.aring@...il.com wrote on Tue, 28 Dec 2021 16:05:43 -0500:

> Hi,
> 
> On Wed, 22 Dec 2021 at 10:57, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > A default channel is selected by default (13), let's clarify that this
> > is page 0 channel 13. Call the right helper to ensure the necessary
> > configuration for this channel has been applied.
> >
> > So far there is very little configuration done in this helper but we
> > will soon add more information (like the symbol duration which is
> > missing) and having this helper called at probe time will prevent us to
> > this type of initialization at two different locations.
> >  
> 
> I see why this patch is necessary because in later patches the symbol
> duration is set at ".set_channel()" callback like the at86rf230 driver
> is doing it.
> However there is an old TODO [0]. I think we should combine it and
> implement it in ieee802154_set_channel() of "net/mac802154/cfg.c".
> Also do the symbol duration setting according to the channel/page when
> we call ieee802154_register_hw(), so we have it for the default
> settings.

While I totally agree on the background idea, I don't really see how
this is possible. Every driver internally knows what it supports but
AFAIU the core itself has no easy and standard access to it?

Another question that I have: is the protocol and center frequency
enough to always derive the symbol rate? I am not sure this is correct,
but I thought not all symbol rates could be derived, like for example
certain UWB PHY protocols which can use different PRF on a single
channel which has an effect on the symbol duration?

> > So far there is very little configuration done in this helper but thanks
> > to this improvement, future enhancements in this area (like setting a
> > symbol duration, which is missing) will be reflected automatically in
> > the default probe state.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> > ---
> >  drivers/net/ieee802154/mac802154_hwsim.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ieee802154/mac802154_hwsim.c b/drivers/net/ieee802154/mac802154_hwsim.c
> > index 62ced7a30d92..b1a4ee7dceda 100644
> > --- a/drivers/net/ieee802154/mac802154_hwsim.c
> > +++ b/drivers/net/ieee802154/mac802154_hwsim.c
> > @@ -778,8 +778,6 @@ static int hwsim_add_one(struct genl_info *info, struct device *dev,
> >
> >         ieee802154_random_extended_addr(&hw->phy->perm_extended_addr);
> >
> > -       /* hwsim phy channel 13 as default */
> > -       hw->phy->current_channel = 13;
> >         pib = kzalloc(sizeof(*pib), GFP_KERNEL);
> >         if (!pib) {
> >                 err = -ENOMEM;
> > @@ -793,6 +791,11 @@ static int hwsim_add_one(struct genl_info *info, struct device *dev,
> >         hw->flags = IEEE802154_HW_PROMISCUOUS | IEEE802154_HW_RX_DROP_BAD_CKSUM;  
> 
> sadly this patch doesn't apply on current net-next/master because
> IEEE802154_HW_RX_DROP_BAD_CKSUM is not set.
> I agree that it should be set, so we need a patch for it.

Right, I just have a patch aside setting this to enforce beacons
checksum were good. I can certainly set this flag officially.

> 
> - Alex
> 
> [0] https://elixir.bootlin.com/linux/v5.16-rc7/source/drivers/net/ieee802154/at86rf230.c#L1059


Thanks,
Miquèl

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ