netdev - Re: [PATCH wpan-next v4 07/11] mac802154: Handle association requests from peers

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: <CAK-6q+j_vgK_5JQH0YZbqZq30J3eGccMdwB-AHKV6pQKJGmMwA@mail.gmail.com>
Date: Tue, 26 Sep 2023 21:37:23 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Alexander Aring <alex.aring@...il.com>, Stefan Schmidt <stefan@...enfreihafen.org>, 
	linux-wpan@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, 
	netdev@...r.kernel.org, David Girault <david.girault@...vo.com>, 
	Romuald Despres <romuald.despres@...vo.com>, Frederic Blain <frederic.blain@...vo.com>, 
	Nicolas Schodet <nico@...fr.eu.org>, Guilhem Imberton <guilhem.imberton@...vo.com>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next v4 07/11] mac802154: Handle association requests
 from peers

Hi,

On Fri, Sep 22, 2023 at 11:51 AM Miquel Raynal
<miquel.raynal@...tlin.com> wrote:
>
> Coordinators may have to handle association requests from peers which
> want to join the PAN. The logic involves:
> - Acknowledging the request (done by hardware)
> - If requested, a random short address that is free on this PAN should
>   be chosen for the device.
> - Sending an association response with the short address allocated for
>   the peer and expecting it to be ack'ed.
>
> If anything fails during this procedure, the peer is considered not
> associated.

I thought a coordinator can also reject requests for _any_ reason and
it's very user specific whatever that reason is.

If we have such a case (that it is very user specific what to do
exactly) this should be able to be controlled by the user space to
have there a logic to tell the kernel to accept or reject the
association.

However, I am fine with this solution, but I think we might want to
change this behaviour in the future so that an application in the user
space has the logic to tell the kernel to accept or reject an
association. That would make sense?

- Alex