Hi, On Wed, Aug 10, 2022 at 7:12 PM Philipp Blum <philipp-blum@xxxxxxxxxxxxxxxxx> wrote: > > Hi, > > sorry, just realized I used the info@ email ^^ > > > What kind of workarounds? I am curious... > > The radvd workaround to distribute a PD. > Ideally I would like it to be as plug & and play as possible. > Connecting the sensors to my router and passing down the PD > automatically. At the end of the day, not everyone is a dev. > Setting up a router is considered to be at least an "administrator" level. You need to at least provide a prefix. The RA message is from the Linux kernel networking branch considered as a user space message (on the transmit side, the receive side it's different), I doubt that this will ever be changed. At the end the user needs to configure something in any case. > > Okay, if you like you could also try [0] on bluetooth networks... I > > never did it on bluetooth. Although I think it does not make any sense > > because it makes only sense on a mesh network and so far I understand > > this is the difference between bluetooth 4.x vs 5.x/upwards and > > currently there is no mesh bluetooth 6lowpan support here (but mesh > > bluetooth on link-layer is there). It's a star topology. I guess what > > you could try out is ndisc-proxy setup which is mostly the same but no > > routing involved and they share the same prefix. > > Btw, I am on Bluetooth 4.2. I had a hard time to even find non audio > only Bluetooth 5.x USB sticks. Yes, it's only star topology so far. Even > though, from my understanding, you could theoretically run a RPL network > behind it. > There are more powerful MCUs that would be able to act as a RPL root. > Even though it probably would be better to use the linux border router > as root. Puts less pressure on the sensor nodes. > I am not familiar with ndisc-proxy. If you could point me to some > resources, that would be very helpful. Going to take a look into it. > Sharing the same prefix would be fine for now, since I only run it in a > star topology anyway. It's also known as arp proxy on IPv4. Just google it, but for IPv6 you need to have a daemon in the background to make it automatically configured. Although I recommend at first to try it with a manual setup by using iproute2. > RPL should be, from my understanding, also work on BLE. RIOT allows > three concurrent connections for BLE, as I remember. > Sure it works on BLE, but here you have a star topology where RPL makes really no sense. It is just one parent with leaf-nodes and radvd will do the same for you. From my point Bluetooth mesh topology is supported by the kernel right now as link-layer but there is no 6LoWPAN adaptation (speaking on Linux kernel level, IETF has standards for it) to run 6LoWPAN on BLE mesh topology. What we currently support is the star topology one which is how Bluetooth works for decades. Only on a mesh RPL becomes interesting. > I don't really understand why rpld only works in a mesh network. > When it runs on 6LoWPAN, it should also run on BLE, or am I missing > something? > I did not say that it does not work, I said it makes no sense to run it on a link-layer star topology. If it's a mesh it looks different. Another thing to test would be a 6CO option [0] which will allow 6lowpan to compress non link-layer prefixes. It makes sense to add one like your prefix destination option in RA. For the arp/ndisc solution you could simply reach all neighbors by its link-local address. To be more clear, the arp/ndisc proxy needs to be configured on the device which was before your "router", then magically all neighbors behind it can be reachable by its link-local... if you want to access it behind your local area network, then you indeed need a global prefix and routing/gateway/etc.. Note that [0] never came upstream (except one patch) because the UAPI in Linux kernel is not stable, I am working on it right now and my progress is at about 25% to make the UAPI stable. :) - Alex [0] https://github.com/linux-wpan/radvd/commit/562e1b3264ac1f352dcc3521f6256d16057775ba
