search

zephyriot / zephyr-issues

0 stars 0 forks source link

Fails to ping Bluetooth IPSP node #1776

Closed nashif closed 7 years ago

nashif commented 7 years ago

Reported by Dawei Wu:

Details: Both A101 and quark se board have this issue. serial console output on A101:

shell> Run IPSP sample[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: c3:36:55:13:5a:13 (random)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x0000, manufacturer 0xffff
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
Bluetooth initialized
Advertising successfully started
Starting to waitConnected
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread

Test Env: host: Ubuntu 16.04,default kernel 4.4.0-21, CSR USB dongle Zephyr revision : master/a375932dee0f1ffb060d189fd31cb4e6baf95bce Arduino101/Quark se board + HCI compatible BLE firmware + IPSP sample node Steps:

Flash FW following https://www.zephyrproject.org/doc/boards/x86/arduino_101/doc/board.html

Flash IPSP sample app ,make sure you have ZEPHYR_GCC_VARIANT=zephyr and ZEPHYR_SDK_INSTALL_DIR=

{code} cd && source zephyr-env.sh cd samples/bluetooth/ipsp make pristine && make flash BOARD=arduino_101 {code}

You will get the MAC addr from serial console or 'hcitool scan' from host , name is 'Test IPSP node'

From host , the connect commands are :

{code}

modprobe bluetooth_6lowpan

# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
# hcitool lecc --random <arduino101 MAC addr>
# echo "connect <arduino101 MAC addr> 2" > /sys/kernel/debug/bluetooth/6lowpan_control

{code}

Run 'ifconfig' from host ,see bt0 there

set ipv6 addreess : # ifconfig bt0 inet6 add 2001:0db8::2/64

run echo-client from host # ping6 -I bt0 bt0 2001:db8::1

Expected Result: ping successfully Actual Result: ping fails

root@zephyr-tcf-client:/home/ostro# ping6 -I bt0 2001:db8::1                                                                                                                                        
PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

(Imported from Jira ZEP-1929)

nashif commented 7 years ago

by Johan Hedberg:

Just to exclude the chance of "read_payload: Failed to allocate, deferring to rx_thread" being the cause of this, could you try setting CONFIG_BLUETOOTH_RX_BUF_COUNT=10 to samples/bluetooth/ipsp/prj.conf and try again?

nashif commented 7 years ago

by Dawei Wu:

Tried ,no helps.

nashif commented 7 years ago

by Luiz Augusto von Dentz:

Global addresses currently doesn't work with Linux, the packets are always dropped for some reason even though they seems to be well formed.

nashif commented 7 years ago

by Dawei Wu:

I didn't see this issue in 1.7 RC4 , so which Global address do you mean ? please clarify. Thanks.

nashif commented 7 years ago

by Luiz Augusto von Dentz:

ping works, echo-client doesn't in any version I tried (1.7 RC4, 1.7, master or net):

ping6 -I bt0 2001:db8::1 PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes 64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=62.6 ms 64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=60.2 ms ^C --- 2001:db8::1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 60.263/61.470/62.678/1.232 ms

./echo-client -i bt0 2001:db8::1 Binding to 2001:db8::2 Timeout while waiting idx 0 len 1 Timeout while waiting idx 1 len 6 Timeout while waiting idx 2 len 4 Timeout while waiting idx 3 len 26 Timeout while waiting idx 4 len 1232 Timeout while waiting idx 5 len 1 Timeout while waiting idx 6 len 256

nashif commented 7 years ago

by Dawei Wu:

Luiz Augusto von Dentz , the issue you said is GH-1738 found in 1.7 RC4. But this bug is found in master branch. Please try again.

nashif commented 7 years ago

by Dawei Wu:

No saw this issue with master/e4aa7412 on arduino101.

nashif commented 7 years ago

by Luiz Augusto von Dentz:

This issue was about ping in the first place, Im not sure why it was reopened if it is just about echo-client, anyway there seems to be something wrong in the routing in the Linux side, so while I do get the data over Bluetooth it is dropped somewhere in the IP stack.

nashif commented 7 years ago

by Sharron LIU:

Dawei Wu keep updating test results in next round of testing.

nashif commented 7 years ago

by Dawei Wu:

Keep watching this issue , we will close it if still no see next time.

nashif commented 7 years ago

by Luiz Augusto von Dentz:

ping6 -I bt0 2001:db8::1 PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes 64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=58.6 ms 64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=56.8 ms 64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=104 ms

What doesn't works is echo-client:

./echo-client -i bt0 2001:db8::1 Binding to 2001:db8::2 Timeout while waiting idx 0 len 1 Timeout while waiting idx 1 len 6 Timeout while waiting idx 2 len 4 Timeout while waiting idx 3 len 26 Timeout while waiting idx 4 len 1232 Timeout while waiting idx 5 len 1 Timeout while waiting idx 6 len 256

But this is actually in the Linux IP side, or echo-client itself, it somehow drops the packets:

[65156.822587] lowpan_iphc_get_tc:966: ecn 0x00 dscp 0x00 [65156.822593] lowpan_iphc_tf_compress:987: tc 0x00 [65156.822599] lowpan_header_compress:1212: send the full source address [65156.822605] lowpan_header_compress:1249: dest address unicast 2001:db8::1 [65156.822612] lowpan_header_compress:1271: header len 38 skb 102 [65156.822623] bt_xmit:610: xmit bt0 to 02:00:00:00:00:01 type 2 IP 6800:: chan ffff9293ef5da000 [65156.822633] bt_xmit:625: ERROR: xmit failed (-11) [65157.006764] chan_resume_cb:981: chan ffff9293ef5da000 conn ffff9293c3f3f800 skb ffff92921fcc3500 [65157.156592] chan_resume_cb:981: chan ffff9293ef5da000 conn ffff9293c3f3f800 skb ffff92921fcc3500 [65157.160540] lowpan_header_decompress:630: NH flag is set, next header carried inline: 3a [65157.160547] lowpan_header_decompress:657: source address stateless compression [65157.160557] lowpan_header_decompress:708: dest: stateless compression mode 0 dest 2001:db8::2 [65157.160566] lowpan_header_decompress:740: skb headroom size = 49, data length = 88 [65157.160577] lowpan_header_decompress:745: IPv6 header dump: version = 6 length = 88 nexthdr = 0x3a hop_lim = 64 dest = 2001:db8::2

nashif commented 7 years ago

by Luiz Augusto von Dentz:

Can you tell if this line tells that the source address is not set:

[65157.160547] lowpan_header_decompress:657: source address stateless compression

Im not sure if the source address matters though, but perhaps echo client expects the global ip address 2001:db8::1 in the response but instead it gets the link-local address.

nashif commented 7 years ago

by Andrei Laperie:

Assigning to Luiz to follow-up at Linux side, see GH-1736?focusedCommentId=17790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17790

nashif commented 7 years ago

by Luiz Augusto von Dentz:

Closing as this is duplicated of GH-1736.

Note: Both ipsp and echo-server are doing the same thing so there is no reason to keep filing bugs for both, also there is no problem with ping/icmp messages but only udp/tcp seems to be affected.

nashif commented 7 years ago

by Dawei Wu:

Not saw this issue with zephyr master/9d0c020a , agree to close this. But not agree that this is duplicated with GH-1736 which says udp over BLE fails, but this issue says ping not work.So change the resolution to 'Not reproduced'.