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.
> 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.
RPL should be, from my understanding, also work on BLE. RIOT allows
three concurrent connections for BLE, as I remember.
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?
best regards
Philipp
