Re: Regarding IPSP over GATT Support in blueZ

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>:
>
> 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@xxxxxxxxxxxx>:
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux