Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)


Priyanka
 

Hi Luiz


I am on

$ uname -r
4.4.0-98-generic

Linux 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

So if I enable  ZEP1656 config option kconifg option in prj.conf (IPSP sample) should it work ?

Or I should upgrade my Linux kernel version?


Thanks

Priyanka



From: Luiz Augusto von Dentz <luiz.dentz@...>
Sent: Tuesday, December 12, 2017 5:00 PM
To: Priyanka Rawat
Cc: zephyr-users@...
Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)
 
Hi Priyanka,

Current IPSP configuration only works with Linux kernel version 4.12
or later, zephyr 1.9 used to have the infamous ZEP1656 config option
set which has been removed in 1.10.

On Tue, Dec 12, 2017 at 1:55 PM, Priyanka Rawat <priyanka.rawat@...> wrote:
> Hi Luiz
>
>
> The HCI firmware hci_blackbox is from KW41Z SDK2.2.
>
> BLE controller remains connected and bt0 does not go down if most of the
> debug logs are disabled in prj.conf
>
> As with debug logs enabled, it prints error
>
> [bt] [ERR] read_payload: Not enough space in buffer
>
> With my test set up k64f (zephyr IPSP)+ kw41z (ble controller), host flow
> control is not enabled.
>
>
> [bt] [WRN] set_flow_control: Controller to host flow control not supported
>
>
> I wonder if we can enable UART flow control on frdm_k64f for HCI transport
> with frdm_kw41z?
>
>  [Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
> controller)+Linux host]
>
> In addition, with recent zephyr master, I have another issue, while testing
> with sample IPSP,  ping fails.
>
> Please note I did not have this issue with zephyr-1.9.1. With same
> configurations, ping worked fine with zephyr-1.9.1
>
>
> Issue with IPSP sample (recent master branch) :
>
>
> BLE address is assigned to k64f board. bluetoothctl utility and its scan
> discover IPSP node.
> BLE connection is up, interface bt0 is up.
> On zephyr side, iface shows interface bluetooth.
>
> Ping to k64f board fails. Ping from Zephyr side to Linux host fails.
>
> Wireshark capture shows Multicast Listener Report Message V2,
>
> Neighbor Solicitation for 2001:db8::2
>
>
>
> zephyr
>
> -----------------
>
>
> [bt] [WRN] set_flow_control: Controller to host flow control not supported
> [bt] [WRN] hci_vs_init: Vendor HCI extensions not available
> [bt] [INF] show_dev_info: Identity: 00:04:9f:00:00:15 (public)
> [bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x000b,
> manufacturer 0x0025
> [bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0x0121
> [bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0004
> [bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0006
> [bt] [DBG] bt_smp_init: (0x20001998) LE SC enabled
> [bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0005
> [bt] [DBG] bt_smp_pkey_ready: (0x200003b4)
> [ipsp] [INF] init_app: Run IPSP sample
>
> [ipsp] [ERR] get_context: Cannot bind IPv6 mcast (-2)
> [ipsp] [ERR] listen: Cannot get network contexts
>
> [bt] [DBG] bt_keys_find_irk: (0x200003b4) 00:60:37:00:00:16 (public)
> [bt] [DBG] bt_l2cap_chan_add: (0x200003b4) conn 0x200008d4 chan 0x20000a28
> [bt] [DBG] bt_smp_accept: (0x200003b4) conn 0x200008d4 handle 32
>
>
> net> ping 2001:db8::2
> Sent a ping to 2001:db8::2
> [bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006e48
> len 57
> [bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006c8c
> len 59
> [bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59
> credits 4
> [bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
> [bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040
> sent 57 total_len 57
> Ping timeout
> net> iface
>
> Interface 0x2000a020 (Bluetooth)
> ================================
> Link addr : 00:04:9F:00:00:15
> MTU       : 1280
> IPv6 unicast addresses (max 3):
>         2001:db8::1 manual preferred infinite
>         fe80::4:9fff:fe00:15 autoconf preferred infinite
> IPv6 multicast addresses (max 2):
>         ff02::1
>         ff02::1:ff00:1
> IPv6 prefixes (max 2):
>         <none>
> IPv6 hop limit           : 64
> IPv6 base reachable time : 30000
> IPv6 reachable time      : 17260
> IPv6 retransmit timer    : 0
> net>
>
> Thanks
> Priyanka
>
> ________________________________
> From: Luiz Augusto von Dentz <luiz.dentz@...>
> Sent: Tuesday, December 5, 2017 6:23 PM
> To: Priyanka Rawat
> Cc: zephyr-users@...;
> zephyr-devel@...
> Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller
> crashes (IPv6 over BLE)
>
> Hi Priyanka,
>
> On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@...>
> wrote:
>> Hello
>>
>> My test set up for IPv6 over BLE is following :
>>
>> At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
>> kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as
>> ble host (flashed with zephyr sample IPSP).
>
> I assume hci_blackbox is not a zephyr based controller is it?
>
>> At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble
>> controller attached to Linux host.
>>
>>
>> [Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
>> controller)+Linux host]
>>
>> Issue with testing IPv6 over BLE :
>>
>> Once the BLE connection is established, within few seconds BLE controller
>> gets disconnected.
>> Either zephyr (recent master branch) crashes or BLE controller crashes or
>> both. Often it is BLE controller that gets disconnected within few
>> seconds.
>> Restarting zephyr might enable establishing the connection once again, but
>> then ble controller goes down immediately.
>
> Im not sure if will be able to help in case the controller is not
> really zephyr based in the other hand we should be able to fix the
> host crash if you provide some traces when that happens.
>
>> After that, I should disconnect the boards and connect again (via usb
>> connection) in order to set up the ble connection again.
>>
>> While on Zephyr side, it always prints connection handle 32
>> On Linux side, the first time connection handle is 32, afterwards it is
>> different (handle 65, 128 etc.,) as shown with "hcitool conn".
>> btmon log shows for specific handle : remote user terminated connection or
>> connection terminated by local host
>
> I guess with Zephyr the controller crashes and restart using the same
> handle, while with Linux it manages to work fine, perhaps this is
> because zephyr attempts to use the host flow control?



--
Luiz Augusto von Dentz

Join users@lists.zephyrproject.org to automatically receive all group messages.