Regarding IPSP over GATT Support in blueZ

Regarding IPSP over GATT Support in blueZ

[Amith Raghunath]

Hi Jukka Rissanen,
     I googled for for IPSP rev1.0.0 profile support in blueZ and also sear=
ched in the blueZ mailing list.
     I could not find info for IPSP over GATT support in blueZ user space s=
tack.
     I could locate 6lowpan over LE code in blueZ kernel space code.
     Kindly let me know of the IPSP over GATT support status in blueZ user =
space code. (i.e whether it is being developed in blueZ).

Regards
Amith

________________________________

http://www.mindtree.com/email/disclaimer.html

Re: Regarding IPSP over GATT Support in blueZ

[Luiz Augusto von Dentz]

Hi Amith,

On Thu, Aug 25, 2016 at 12:55 PM, Amith Raghunath
<Amith.Raghunath@mindtree.com> wrote:
> Hi Jukka Rissanen,
>      I googled for for IPSP rev1.0.0 profile support in blueZ and also searched in the blueZ mailing list.
>      I could not find info for IPSP over GATT support in blueZ user space stack.
>      I could locate 6lowpan over LE code in blueZ kernel space code.
>      Kindly let me know of the IPSP over GATT support status in blueZ user space code. (i.e whether it is being developed in blueZ).

It is currently pending the implementation of MGMT interface, but you
can use it with debugfs:

$ modprobe bluetooth_6lowpan
$ echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable

Then to connect:

$echo "connect <bdaddr> <type>" > /sys/kernel/debug/bluetooth/6lowpan_control

-- 
Luiz Augusto von Dentz

RE: Regarding IPSP over GATT Support in blueZ

[Amith Raghunath]

SGkgTHVpeiwNCg0KPiBJdCBpcyBjdXJyZW50bHkgcGVuZGluZyB0aGUgaW1wbGVtZW50YXRpb24g
b2YgTUdNVCBpbnRlcmZhY2UsIGJ1dCB5b3UgY2FuIHVzZSBpdCB3aXRoIGRlYnVnZnM6DQoNClRo
YW5rIHlvdSBmb3IgYW5zd2VyaW5nIHRoZSBxdWVyeS4NCkkgaGF2ZSB0cmllZCB0aGlzIHNldHVw
IG9uIDIgVWJ1bnR1IDE2LjA0IG1hY2hpbmVzIHdpdGggY3NyIDQuMCBkb25nbGUuDQpUaHJvdWdo
IHRoZSBkZWJ1Z2ZzIGFwcHJvYWNoIHBpbmc2IHRvIHRoZSByZW1vdGUgbWFjaGluZSBpcyB3b3Jr
aW5nLg0KDQpJIGhhdmUgYW5vdGhlciBxdWVyeToNCkluIHRoZSA2bG93cGFuLmMgY29kZQ0KdGhl
IGZ1bmN0aW9uICJyZWN2X3BrdCIgc2VuZHMgdGhlIHJlY2VpdmVkIHBhY2tldCB0byB0aGUgdXBw
ZXIgKHByb3RvY29sKSBsZXZlbHMuDQpUaGUgZnVuY3Rpb24gImJ0X3htaXQiIHdpbGwgZWl0aGVy
IHNlbmQgdGhlIHBrdCB0byBhbGwgaXRzIHBlZXJzIG9yIHNlbmQgaXQgdG8gb25lIG9mIHRoZSBw
ZWVycy4NCg0KSW4gdGhlIGlldGYgUkZDNzY2OCBkb2N1bWVudCwgaXQgc3RhdGVzIHRoYXQgMiA2
TEJOcyBjYW4gZXhjaGFuZ2UgcGFja2V0cyB0aHJvdWdoIGEgNkxCUi4NCldpdGggcmVnYXJkIHRv
IHRoaXMgSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlcmllczoNCjEuIFRoZSA2TEJSIGhhcyB0byBm
b3J3YXJkIHRoZSBwYWNrZXRzIHNlbnQgYnkgb25lIG5vZGUgdG8gYW5vdGhlciBub2RlIGJhc2Vk
IG9uIHRoZSBsaW5rLWxvY2FsIGFkZHJlc3MuIElzIHRoaXMgc2NlbmFyaW8gc3VwcG9ydGVkIGlu
IHRoZSBwcmVzZW50IGNvZGUgYmFzZSA/DQoyLiBBcmUgYWxsIHRoZSB1c2UgY2FzZXMgbWVudGlv
bmVkIGluIFJGQzc2NjggKGluY2x1ZGluZyBuZWlnaGJvciBkaXNjb3ZlcnkpIHN1cHBvcnRlZCBi
eSB0aGUgcHJlc2VudCBjb2RlIGJhc2UgPw0KMy4gV2hhdCBpcyB0aGUgcHJlc2VudCBzdGF0dXMg
b2YgYmx1ZXRvb3RoXzZsb3dwYW4gY29kZSB3aXRoIHJlZmVyZW5jZSB0byBpZXRmIFJGQzc2Njgg
ZG9jdW1lbnQgPw0KDQpSZWdhcmRzLA0KQW1pdGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KaHR0cDovL3d3dy5taW5kdHJlZS5jb20vZW1haWwvZGlzY2xhaW1lci5odG1s
DQo=

Re: Regarding IPSP over GATT Support in blueZ

[Alexander Aring]

Hi,

resend my mail because gmail fail, sorry! I hope it works now.

2016-09-04 20:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>
> Hi,
>
> currently with my gmail mail account, because I am not subscribed on linux-bluetooth with
> another mail address, sorry.
>
> 2016-09-01 17:49 GMT+02:00 Amith Raghunath <Amith.Raghunath@mindtree.com>:
>>
>> Hi Luiz,
>>
>> > It is currently pending the implementation of MGMT interface, but you can use it with debugfs:
>>
>> Thank you for answering the query.
>> I have tried this setup on 2 Ubuntu 16.04 machines with csr 4.0 dongle.
>> Through the debugfs approach ping6 to the remote machine is working.
>>
>> I have another query:
>> In the 6lowpan.c code
>> the function "recv_pkt" sends the received packet to the upper (protocol) levels.
>
>
> yep.
>
>>
>> The function "bt_xmit" will either send the pkt to all its peers or send it to one of the peers.
>>
>
> depends on multicast or not. RFC7668 says something about only to the mulitcast listener
> group. But this isn't supported yet, so it sends it to all.
>
>>
>> In the ietf RFC7668 document, it states that 2 6LBNs can exchange packets through a 6LBR.
>> With regard to this I have the following queries:
>> 1. The 6LBR has to forward the packets sent by one node to another node based on the link-local address. Is this scenario supported in the present code base ?
>
>
> so far I know, no.
>
>>
>> 2. Are all the use cases mentioned in RFC7668 (including neighbor discovery) supported by the present code base ?
>
>
> If you mean RFC6775, no we either have no 802.15.4 6LoWPAN for it, but we introduced
> recently some ndisc_ops [2] structure where we can do "per-device (6LoWPAN interface)" changes during runtime.
> I hope this layer will help us to implement RFC6775.
>
>>
>> 3. What is the present status of bluetooth_6lowpan code with reference to ietf RFC7668 document ?
>>
>
> Some things works and some things not. :-)
>
> There exist many known issues (in my opinion) with the current implementation.
>
> - Current implementation doesn't use any IPv6 ndisc functionality. The L2 address will be
>   reconstructed by L3 address and use some net core POINT_TO_POINT mechanism, which I
>   don't know what it's currently exactly does.
>
> - The call of l2cap_chan_send need to be held the chan mutex lock.
>
> - The device address is the IID, which means if you fix the first issue the address option
>   will be the 8 byte Interface Identifier according to rfc7668.
>
> - A tx deadlock which seems to be bluetooth subsystem related.
>
> - Races, e.g. [0] which sets some skb control block information which is not per l2cap_chan
>   instance.
>
> - ....
>
> There exists some RFC about fixing the above issues, this will still not have support to ping
> another 6LN with it's link-local over a 6LBR. This sounds like some fun to implement it. :-)
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/bluetooth/6lowpan.c#L985
> [1] http://www.spinics.net/lists/linux-wpan/msg04124.html
> [2] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/6lowpan/ndisc.c#n230

RE: Regarding IPSP over GATT Support in blueZ

[Amith Raghunath]

SGkgQWxleCwNCg0KPiAyMDE2LTA5LTA0IDIwOjEzIEdNVCswMjowMCBBbGV4YW5kZXIgQXJpbmcg
PGFsZXguYXJpbmdAeHh4eHh4eHh4PjoNCj4+DQo+PiAyMDE2LTA5LTAxIDE3OjQ5IEdNVCswMjow
MCBBbWl0aCBSYWdodW5hdGggPEFtaXRoLlJhZ2h1bmF0aEB4eHh4eHh4eHg+Og0KPj4+DQo+Pj4N
Cj4+PiAxLiBUaGUgNkxCUiBoYXMgdG8gZm9yd2FyZCB0aGUgcGFja2V0cyBzZW50IGJ5IG9uZSBu
b2RlIHRvIGFub3RoZXIgbm9kZSBiYXNlZCBvbiB0aGUgbGluay1sb2NhbCBhZGRyZXNzLiBJcyB0
aGlzIHNjZW5hcmlvIHN1cHBvcnRlZCBpbiB0aGUgcHJlc2VudCBjb2RlIGJhc2UgPw0KPj4NCj4+
DQo+PiBzbyBmYXIgSSBrbm93LCBuby4NCj4+DQoNCkluIFJGQzc2NjggaXQgc3RhdGVzIHRoYXQg
IiA2TE5zIGNvbm5lY3RlZCB0byB0aGUgc2FtZSA2TEJSIGhhdmUgdG8gY29tbXVuaWNhdGUgd2l0
aCBlYWNoIG90aGVyIGJ5DQp1c2luZyB0aGUgc2hhcmVkIHByZWZpeCB1c2VkIG9uIHRoZSBzdWJu
ZXQuIg0KSXQgaXMgbm90IHRoZSBsaW5rLWxvY2FsIGFkZHJlc3MgdGhhdCB3YXMgcmVmZXJyaW5n
IHRvIGluIHRoZSBlYXJsaWVyIHF1ZXJ5LCBraW5kbHkgbGV0IG1lIGtub3cgd2hldGhlciB0aGlz
IHNoYXJlZCBwcmVmaXggZmVhdHVyZSBhbmQgdGhlIDZMQlIgcm91dGluZyBtZWNoYW5pc20gYmFz
ZWQgb24gdGhpcyBzaGFyZWQgcHJlZml4IGlzIHlldCB0byBiZSBpbXBsZW1lbnRlZC4gSSBjaGVj
a2VkIHRoZSBuZXQvYmx1ZXRvb3RoLzZsb3dwYW4uYyBvZiBsaW51eCBrZXJuZWwgNC43LjEsIGNv
dWxkIG5vdCBmaW5kIHRoaXMgZmVhdHVyZS4gVGhpcyB3b3VsZCBiZSByZXF1aXJlZCB0byBzdXBw
b3J0IHRoZSAiSXNvbGF0ZWQgQmx1ZXRvb3RoIExFIE5ldHdvcmsiIHRvcG9sb2d5Lg0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KaHR0cDovL3d3dy5taW5kdHJlZS5j
b20vZW1haWwvZGlzY2xhaW1lci5odG1sDQo=

RE: Regarding IPSP over GATT Support in blueZ

[Amith Raghunath]

Hi Alex,

> 2016-09-04 20:13 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>:
>>
>> 2016-09-01 17:49 GMT+02:00 Amith Raghunath <Amith.Raghunath@xxxxxxxxx>:
>>>
>>>
>>> 1. The 6LBR has to forward the packets sent by one node to another node based on the link-local address. Is this scenario supported in the present code base ?
>>
>>
>> so far I know, no.
>>

In RFC7668 it states that " 6LNs connected to the same 6LBR have to communicate with each other by
using the shared prefix used on the subnet."
It is not the link-local address that was referring to in the earlier query, kindly let me know whether this shared prefix feature and the 6LBR routing mechanism based on this shared prefix is yet to be implemented. I checked the net/bluetooth/6lowpan.c of linux kernel 4.7.1, could not find this feature. This would be required to support the "Isolated Bluetooth LE Network" topology.



________________________________

http://www.mindtree.com/email/disclaimer.html

Re: Regarding IPSP over GATT Support in blueZ

[Alexander Aring]

Hi,

On 09/06/2016 01:50 PM, Amith Raghunath wrote:
> Hi Alex,
> 
>> 2016-09-04 20:13 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>:
>>>
>>> 2016-09-01 17:49 GMT+02:00 Amith Raghunath <Amith.Raghunath@xxxxxxxxx>:
>>>>
>>>>
>>>> 1. The 6LBR has to forward the packets sent by one node to another node based on the link-local address. Is this scenario supported in the present code base ?
>>>
>>>
>>> so far I know, no.
>>>
> 
> In RFC7668 it states that " 6LNs connected to the same 6LBR have to communicate with each other by
> using the shared prefix used on the subnet."
> It is not the link-local address that was referring to in the earlier query, kindly let me know whether this shared prefix feature and the 6LBR routing mechanism based on this shared prefix is yet to be implemented. I checked the net/bluetooth/6lowpan.c of linux kernel 4.7.1, could not find this feature. This would be required to support the "Isolated Bluetooth LE Network" topology.
> 

Is this not simple run some Router Advertisment Daemon, e.g. radvd on
the 6LBR Node and then putting a PIO into the RA messages. Maybe a ULA
prefix for your $SUBNET? Then you have the routing mechanism based on
your prefix.

Additional you could also add a 6CO to compress the used prefix. See
forked radvd branch [0] which used a non-stable UAPI to provide access
to 6LoWPAN stateful compression.

---

for the link-local case I through it must be possible to access 6LN's
over it's their link-local address. Example

6LN(A) <---> 6LBR <---> 6LN(B)

so it must be possible somehow to have a connection from A to B by using
the link-local address. But RFC7668 says:

"6LN-to-6LN communications using link-local addresses are not possible."

So I think it's simple not possible and you must do the shared prefix
and this is what you want (I think I finally understand), but this is not
the job of 6LoWPAN subsystem - you need to do right IPv6 setup.

- Alex

[0] https://github.com/linux-wpan/radvd/tree/6lowpan

RE: Regarding IPSP over GATT Support in blueZ

[Amith Raghunath]

Subject: Regarding IPSP over GATT Support in blueZ
From: Amith Raghunath <Amith.Raghunath@xxxxxxxxxxxx>
Date: Thu, 25 Aug 2016 09:55:46 +0000

Hi Jukka Rissanen,
     I googled for for IPSP rev1.0.0 profile support in blueZ and also sear=
ched in the blueZ mailing list.
     I could not find info for IPSP over GATT support in blueZ user space s=
tack.
     I could locate 6lowpan over LE code in blueZ kernel space code.
     Kindly let me know of the IPSP over GATT support status in blueZ user =
space code. (i.e whether it is being developed in blueZ).

Regards
Amith

________________________________

http://www.mindtree.com/email/disclaimer.html