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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
