* 6LoWPAN (IPv6 over BLE) neighbor discovery @ 2022-08-09 20:13 Philipp Blum 2022-08-10 0:17 ` Alexander Aring 0 siblings, 1 reply; 6+ messages in thread From: Philipp Blum @ 2022-08-09 20:13 UTC (permalink / raw) To: linux-wpan Hey, I am currently working on a demonstration for the W3C TPAC next month. Just wanted to get an update on this topic, since RIOT uses it in IPv6 over BLE. best regards Philipp Blum ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 6LoWPAN (IPv6 over BLE) neighbor discovery 2022-08-09 20:13 6LoWPAN (IPv6 over BLE) neighbor discovery Philipp Blum @ 2022-08-10 0:17 ` Alexander Aring 2022-08-10 1:40 ` Philipp Blum 0 siblings, 1 reply; 6+ messages in thread From: Alexander Aring @ 2022-08-10 0:17 UTC (permalink / raw) To: Philipp Blum; +Cc: linux-wpan - ML, linux-bluetooth Hi, On Tue, Aug 9, 2022 at 4:24 PM Philipp Blum <info@desertmonitor.com> wrote: > > Hey, > > I am currently working on a demonstration for the W3C TPAC next month. > Just wanted to get an update on this topic, since RIOT uses it in IPv6 > over BLE. > Which neighbor discovery are you talking about? Can you be more specific here? I am not aware that any 6LoWPAN implementation uses any optimized in-kernel IPv6 neighbor discovery for any low power/lossy network, we are still using the default IPv6 one which should probably still work if the other side supports it. In 802.15.4 we tweaked it a little bit to support the short address into the address option as RFC4944 describes it [0] that autoconfiguration can use it. I added linux-bluetooth in cc. - Alex [0] https://www.rfc-editor.org/rfc/rfc4944#section-8 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 6LoWPAN (IPv6 over BLE) neighbor discovery 2022-08-10 0:17 ` Alexander Aring @ 2022-08-10 1:40 ` Philipp Blum 2022-08-10 22:15 ` Alexander Aring 0 siblings, 1 reply; 6+ messages in thread From: Philipp Blum @ 2022-08-10 1:40 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan - ML, linux-bluetooth Hi, > Which neighbor discovery are you talking about? Can you be more > specific here? Sorry, I cannot, since I am not too familiar with the network stack. From my point of view, mostly as a user of the stack, I can't pass down IPv6-PDs from my router down to the RIOT RPL network. I need some workarounds with radvd in order to distribute the PD. There is a markdown file about it: https://github.com/RIOT-OS/RIOT/blob/master/pkg/nimble/README.ipv6-over-ble.md People in the matrix chat pointed me towards the mailing list. best regards Philipp Blum On 10.08.22 02:17, Alexander Aring wrote: > Hi, > > On Tue, Aug 9, 2022 at 4:24 PM Philipp Blum <info@desertmonitor.com> wrote: >> >> Hey, >> >> I am currently working on a demonstration for the W3C TPAC next month. >> Just wanted to get an update on this topic, since RIOT uses it in IPv6 >> over BLE. >> > > Which neighbor discovery are you talking about? Can you be more > specific here? I am not aware that any 6LoWPAN implementation uses any > optimized in-kernel IPv6 neighbor discovery for any low power/lossy > network, we are still using the default IPv6 one which should probably > still work if the other side supports it. In 802.15.4 we tweaked it a > little bit to support the short address into the address option as > RFC4944 describes it [0] that autoconfiguration can use it. > > I added linux-bluetooth in cc. > > - Alex > > [0] https://www.rfc-editor.org/rfc/rfc4944#section-8 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 6LoWPAN (IPv6 over BLE) neighbor discovery 2022-08-10 1:40 ` Philipp Blum @ 2022-08-10 22:15 ` Alexander Aring 2022-08-10 23:04 ` Philipp Blum 0 siblings, 1 reply; 6+ messages in thread From: Alexander Aring @ 2022-08-10 22:15 UTC (permalink / raw) To: Philipp Blum; +Cc: linux-wpan - ML, linux-bluetooth Hi, On Tue, Aug 9, 2022 at 9:41 PM Philipp Blum <info@desertmonitor.com> wrote: > > Hi, > > > Which neighbor discovery are you talking about? Can you be more > > specific here? > > Sorry, I cannot, since I am not too familiar with the network stack. > From my point of view, mostly as a user of the stack, I can't pass down > IPv6-PDs from my router down to the RIOT RPL network. > I need some workarounds with radvd in order to distribute the PD. What kind of workarounds? I am curious... > There is a markdown file about it: > https://github.com/RIOT-OS/RIOT/blob/master/pkg/nimble/README.ipv6-over-ble.md > 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. > People in the matrix chat pointed me towards the mailing list. I see, on this layer it would be linux-wpan and linux-bluetooth. - Alex [0] https://github.com/linux-wpan/rpld ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 6LoWPAN (IPv6 over BLE) neighbor discovery 2022-08-10 22:15 ` Alexander Aring @ 2022-08-10 23:04 ` Philipp Blum 2022-08-14 14:14 ` Alexander Aring 0 siblings, 1 reply; 6+ messages in thread From: Philipp Blum @ 2022-08-10 23:04 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan - ML, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 6LoWPAN (IPv6 over BLE) neighbor discovery 2022-08-10 23:04 ` Philipp Blum @ 2022-08-14 14:14 ` Alexander Aring 0 siblings, 0 replies; 6+ messages in thread From: Alexander Aring @ 2022-08-14 14:14 UTC (permalink / raw) To: Philipp Blum; +Cc: linux-wpan - ML, linux-bluetooth Hi, On Wed, Aug 10, 2022 at 7:12 PM Philipp Blum <philipp-blum@desertmonitor.com> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-08-14 14:14 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-09 20:13 6LoWPAN (IPv6 over BLE) neighbor discovery Philipp Blum 2022-08-10 0:17 ` Alexander Aring 2022-08-10 1:40 ` Philipp Blum 2022-08-10 22:15 ` Alexander Aring 2022-08-10 23:04 ` Philipp Blum 2022-08-14 14:14 ` Alexander Aring
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).