Hi,
On Mon, Oct 24, 2022 at 8:16 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
> Hi Alexander,
>
> > > About the way we handle the PAN coordinator role I have a couple of
> > > questions:
> > > - shall we consider only the PAN coordinator to be able to accept
> > > associations or is any coordinator in the PAN able to do it? (this is
> > > not clear to me)
> >
> > Me either, it sounds for me that coordinators are "leaves" and pan
> > coordinators are not. It is like in IPv6 level it is a host or router.
>
> I went through the spec once again and I actually (re)discovered
> Annexe E "Time-slot relaying based link extension (TRLE)" which indeed
> seems to tell us that relaying is an extension, so otherwise
> coordinators are "leaves" as you say.
>
okay.
> > > - If a coordinator receives a packet with no destination it should
> > > expect it to be targeted at the PAN controller. Should we consider
> > > relaying the packet?
> >
> > I guess it depends what the standard says here?
>
> While we don't implement TRLE (and this is a project on its own) I
> guess we should not perform any relaying.
>
Yes, it's a project on its own.
> > > - Is relaying a hardware feature or should we do it in software?
> > >
> >
> > I think for SoftMAC it is only the address filter which needs to be
> > changed. The rest is in software. So far what I can see here.
>
> If we need to change the address filters then I guess the hardware is
> broken, it would not be usable. The hardware must have a "PAN
> controller" bit to know whether or not the packet must be dropped or
> not when there is no destination field.
>
yes, I was more concerned here that in those "non leaves" the address
filter is set so as it's required to do such handling. Sure hardware
which needs to support it to change it as e.g. ack vs no ack needs to
be reported back - same thing.
> > Question is what we are using here in the Linux kernel to provide such
> > functionality...
> >
> > e.g. see:
> >
> > include/net/dst.h
> >
> > > Regarding the situation where we would have NODE + MONITOR or COORD +
> > > MONITOR, while the interface creation would work, both could not be
> > > open at the same time because the following happens:
> > > mac802154_wpan_open() {
> > > ieee802154_check_concurrent_iface() {
> > > ieee802154_check_mac_settings() {
> > > /* prevent the two interface types from being
> > > * open at the same time because the filtering
> > > * needs are not compatible. */
> > > }
> > > }
> > > }
> > >
> > > Then, because you asked me to anticipate if we ever want to support more
> > > than one NODE or COORD interface at the same time, or at least not to
> > > do anything that would lead to a step back on this regard, I decided I
> > > would provide all the infrastructure to gracefully handle this
> > > situation in the Rx path, even though right now it still cannot happen
> > > because when opening an interface, ieee802154_check_concurrent_iface()
> > > will also prevent two NODE / COORD interfaces to be opened at the same
> > > time.
> >
> > yes, but you are assuming the actual hardware here. A hardware with
> > multiple address filters can indeed support other interfaces at the
> > same time. I can also name one, hwsim and a real one - atusb.
>
> I have this use case in mind, I know the support for it may be
> brought at some point, and I think my proposal is future proof on this
> aspect. Isn't it?
It is.
- Alex
