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. 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. (it's for setting the destination pan) You could insert some routes to route over different pans via internal lowpanX interfaces, if you want that. What doesn't work and what I don't want to plan is one wpan interfaces and different lowpan interfaces on top of it, which operates on different source pans (on lowpan interface layer). The reason is that IEEE 802.15.4 can have only one source PAN for one MAC instance (which is part of wpan interface and not lowpan). If somebody has another idea to deal with different pan settings I would like to hear that, then I can think about it. - 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