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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Alexander,

aahringo@redhat.com wrote on Tue, 26 Sep 2023 21:31:09 -0400:

> Hi,
> 
> On Mon, Sep 25, 2023 at 3:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Sun, 24 Sep 2023 20:13:34 -0400:
> >  
> > > Hi,
> > >
> > > On Fri, Sep 22, 2023 at 11:51 AM Miquel Raynal
> > > <miquel.raynal@bootlin.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.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > >  include/net/cfg802154.h         |   7 ++
> > > >  include/net/ieee802154_netdev.h |   6 ++
> > > >  net/ieee802154/core.c           |   7 ++
> > > >  net/ieee802154/pan.c            |  30 +++++++
> > > >  net/mac802154/ieee802154_i.h    |   2 +
> > > >  net/mac802154/rx.c              |   8 ++
> > > >  net/mac802154/scan.c            | 142 ++++++++++++++++++++++++++++++++
> > > >  7 files changed, 202 insertions(+)
> > > >
> > > > diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
> > > > index 9b036ab20079..c844ae63bc04 100644
> > > > --- a/include/net/cfg802154.h
> > > > +++ b/include/net/cfg802154.h
> > > > @@ -583,4 +583,11 @@ struct ieee802154_pan_device *
> > > >  cfg802154_device_is_child(struct wpan_dev *wpan_dev,
> > > >                           struct ieee802154_addr *target);
> > > >
> > > > +/**
> > > > + * cfg802154_get_free_short_addr - Get a free address among the known devices
> > > > + * @wpan_dev: the wpan device
> > > > + * @return: a random short address expectedly unused on our PAN
> > > > + */
> > > > +__le16 cfg802154_get_free_short_addr(struct wpan_dev *wpan_dev);
> > > > +
> > > >  #endif /* __NET_CFG802154_H */
> > > > diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
> > > > index 16194356cfe7..4de858f9929e 100644
> > > > --- a/include/net/ieee802154_netdev.h
> > > > +++ b/include/net/ieee802154_netdev.h
> > > > @@ -211,6 +211,12 @@ struct ieee802154_association_req_frame {
> > > >         struct ieee802154_assoc_req_pl assoc_req_pl;
> > > >  };
> > > >
> > > > +struct ieee802154_association_resp_frame {
> > > > +       struct ieee802154_hdr mhr;
> > > > +       struct ieee802154_mac_cmd_pl mac_pl;
> > > > +       struct ieee802154_assoc_resp_pl assoc_resp_pl;
> > > > +};
> > > > +
> > > >  struct ieee802154_disassociation_notif_frame {
> > > >         struct ieee802154_hdr mhr;
> > > >         struct ieee802154_mac_cmd_pl mac_pl;
> > > > diff --git a/net/ieee802154/core.c b/net/ieee802154/core.c
> > > > index a08d75dd56ad..1670a71327a7 100644
> > > > --- a/net/ieee802154/core.c
> > > > +++ b/net/ieee802154/core.c
> > > > @@ -200,11 +200,18 @@ EXPORT_SYMBOL(wpan_phy_free);
> > > >
> > > >  static void cfg802154_free_peer_structures(struct wpan_dev *wpan_dev)
> > > >  {
> > > > +       struct ieee802154_pan_device *child, *tmp;
> > > > +
> > > >         mutex_lock(&wpan_dev->association_lock);
> > > >
> > > >         kfree(wpan_dev->parent);
> > > >         wpan_dev->parent = NULL;
> > > >
> > > > +       list_for_each_entry_safe(child, tmp, &wpan_dev->children, node) {
> > > > +               list_del(&child->node);
> > > > +               kfree(child);
> > > > +       }
> > > > +
> > > >         mutex_unlock(&wpan_dev->association_lock);
> > > >  }
> > > >
> > > > diff --git a/net/ieee802154/pan.c b/net/ieee802154/pan.c
> > > > index 9e1f1973c294..e99c64054dcb 100644
> > > > --- a/net/ieee802154/pan.c
> > > > +++ b/net/ieee802154/pan.c
> > > > @@ -73,3 +73,33 @@ cfg802154_device_is_child(struct wpan_dev *wpan_dev,
> > > >         return NULL;
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(cfg802154_device_is_child);
> > > > +
> > > > +__le16 cfg802154_get_free_short_addr(struct wpan_dev *wpan_dev)
> > > > +{
> > > > +       struct ieee802154_pan_device *child;
> > > > +       __le16 addr;
> > > > +
> > > > +       lockdep_assert_held(&wpan_dev->association_lock);
> > > > +
> > > > +       do {
> > > > +               get_random_bytes(&addr, 2);
> > > > +               if (addr == cpu_to_le16(IEEE802154_ADDR_SHORT_BROADCAST) ||
> > > > +                   addr == cpu_to_le16(IEEE802154_ADDR_SHORT_UNSPEC))
> > > > +                       continue;
> > > > +
> > > > +               if (wpan_dev->short_addr == addr)
> > > > +                       continue;
> > > > +
> > > > +               if (wpan_dev->parent && wpan_dev->parent->short_addr == addr)
> > > > +                       continue;
> > > > +
> > > > +               list_for_each_entry(child, &wpan_dev->children, node)
> > > > +                       if (child->short_addr == addr)
> > > > +                               continue;
> > > > +
> > > > +               break;
> > > > +       } while (1);
> > > > +  
> > >
> > > I still believe that this random 2 bytes and check if it's already
> > > being used is wrong here. We need something to use the next free
> > > available number according to the data we are storing here.  
> >
> > This issue I still have in mind is when you have this typology:
> >
> > device A -------> device B --------> device C <-------- device D
> > (leaf)            (coord)            (PAN coord)            (leaf)
> >
> > B associates with C
> > A associates with B
> > D associates with C
> >
> > If B and C run Linux's stack, they will always have the same short
> > address. Yes this can be handled (realignment procedure). But any time
> > this happens, you'll have a load of predictable realignments when A and
> > D get in range with B or C.
> >  
> 
> I see that it can be "more" predictable, but what happens when there
> is the same short address case with the random number generator? It
> sounds to me like there needs to be a kind of duplicate address
> detection going on and then choose another one, if 802.15.4 even
> handles this case...

Yes it may happen, and yes it is handled by the spec (I did not
implement it yet). When such a situation occurs (two devices using the
same short address in a given PAN), the third-party device which
detects the faulty situation must notify its coordinator and the
coordinator (IIRC) must allocate a new short address as part of a
realignment procedure.

> I am also thinking that there is only one number left and the random
> generator runs multiple times to find the last one aka "it's random
> you can never be sure", when it always returns the same address.

I'll try to summarize the two issues and solutions we have:
- incremental short address: if two coordinators distribute
  short addresses in a PAN, at the time we perform a realignment
  procedure, if Coord A has allocated 1 short address (0) and Coord B
  in the same PAN has allocated 10 short addresses (from 0 to 9), you
  know that the device that needs a new address will be given 1, which
  will lead to a realignment, then 2, then 3... and produce a *lot* of
  noise. However despite being long on big network, we can assume the
  time to find the relevant address is bounded.
- random short address: no conflict should happen following a
  realignment procedure (assuming regular-sized networks, probability
  is very low, close to 1/65000) however in case we have a huge
  network, the time taken to find a free slot is unbounded.

At this stage I believe the former issue is more likely to happen than
the second, but the second is a bit critical as it can lead to DoS
situations. One easy way to mitigate this is to limit the number of
devices on the network (as you said in another mail, we can refuse
devices arbitrarily), which is the first denial procedure I've
implemented, knowing that it should be improved as well, as that can be
done later without much additional constraints.

> However, that's only my thoughts about it and hopefully can be
> improved in future.

Yes, I am not convinced this is the perfect choice but at least it's
simple enough and will work like a charm on small networks.

Thanks,
Miquèl