Re: handling multiple MAC instances (multiple address filters)

[Alexander Aring <alex.aring@gmail.com>]

Hi,

took a shower again and detected issues.

On Sun, Jul 16, 2017 at 11:08:06AM +0200, Alexander Aring wrote:
> On Fri, Jul 14, 2017 at 12:21:52PM +0200, Michael Richardson wrote:
> > 
> > Alexander Aring <alex.aring@gmail.com> wrote:
> >     > So this is for me "we can only have a non-changing _source_ PAN". But
> >     > you could run more than one 802.15.4 MAC instances on one 802.15.4 PHY.
> >     > Which allows to run multiple wpan interfaces with different source PANs.
> > 
> > I'm not parsing the difference.
> > 
> 
> ok.
> 
> >     > In short: You cannot handle multiple pan support on the same interface,
> >     > you need create other interfaces to run on other pans then. Is that what
> >     > you are looking for? I know unstrung need to have support to deal with
> >     > multiple interfaces then...
> > 
> > What does "same interface" mean here?
> > Differrent hardware is needed, or just different lowpanX interfaces?
> > 
> 
> just different lowpanX interfaces.
> 
>       ____PHY0____
>       |   ...   |
>     wpan0 ... wpanX   <---- can have different source pan settings,
>       |         |           destination can also be different over
>       |         |           af802154 socket communication.
>       |         |           (it's for setting the source pan)
>       |   ,,,   |
>   lowpan0 ... lowpanX <---- can have different destination pan as
>                             ``default destination pan''. _Maybe_ you
> 			    could change overwrite default destination
> 			    pan by CMSG attribute.

I think we cannot change the destination pan while interface running, so
handle only one different destination pan per interface and while it's
up.

The reason is simple: There is no address option for the destination pan
per neighbor cache - there is only one for short address and for this
reason we need always need to know on which pan the neighbor operates.
When doing ifdown on ipv6 capable interface - neighbor cache will be
flushed so we can change destination pan then.

Maybe 6lo working group will write something about handle destination
pan right. Don't know - maybe extract the info from received mac header?
But this sounds weird - because we don't do that for short address,
maybe there will be some PAN address option field come for ndisc
handling.

I mean we cannot handle anyway multiple destination pans on one
interface, because we save the short address only per neighbor and it's
not unique without the right pan. I don't see right now that this can
be working. :-/

So forget to change destination pan per CMSG attribute or per runtime
(interface is up).

> 			    At least we need CMSG attribute I think,
> 			    because 0xffff pan which is broadcast pan.
> 			    We should only allow "unicast" pans in
> 			    lowpanX generation as destination.

yea, forget to handle 0xffff ever - I don't know how this can be useful, see
above.

- Alex