Arduino_101 doesn't respond to ipv6 ping request after enable echo_server ipv6

[zephyrbot]

Reported by jiequan wu:

Configuration

x86 Bug detailed description =================== Arduino_101 doesn't response ipv6 ping request affer enable echo_server ipv6 ================== 1. cd samples/net/echo_server 2. Enable ipv6 and disable ipv4 prj_arduino_101.conf: CONFIG_NET_IPV4=n CONFIG_NET_IPV6=y 3. make pristine && make BOARD=arduino_101 flash 4. Connect Arduino to the LAN with ENC28J60 5. Set ipv6 address on Ubuntu $ sudo ifconfig eth1 inet6 add 2001:0db8::2/64 7. open serial port 8. ping6 2001:0db8::1 Expected Result ============= Arduino_101 can response ipv6 ping request affer enable echo_server ipv6 Actual Result ========== Arduino_101 doesn't response ipv6 ping request affer enable echo_server ipv6 zephyr/samples/net/echo_server$ ping6 2001:0db8::1 PING 2001:0db8::1(2001:db8::1) 56 data bytes From 2001:db8::2 icmp_seq=24 Destination unreachable: Address unreachable From 2001:db8::2 icmp_seq=37 Destination unreachable: Address unreachable From 2001:db8::2 icmp_seq=38 Destination unreachable: Address unreachable From 2001:db8::2 icmp_seq=39 Destination unreachable: Address unreachable (Imported from Jira ZEP-1544)

[zephyrbot]

by Ravi kumar Veeramally:

• arduino_101_ethernet_ipv4_ipv6.pcapng (size: 8420)

[zephyrbot]

by jiequan wu:

The latest commit (commit 89f4bf7c7e8df7e19bc966c6017244f8715a1571 branch: master), I test echo_server ipv6 is not working. And dns_client 、echo_client ipv6 is ok.

[zephyrbot]

by jiequan wu:

And the echo_client ipv6 is not stable.

[zephyrbot]

by Sharron LIU:

jiequan wu , please create a new JIRA for "echo_client not stable". One issue one ticket.

[zephyrbot]

by Jukka Rissanen:

We setup an environment (a101+enc eth shield) and tried these scenarios using Linux host at the other end:

• ping IPv4 works just fine
• zephyr IP stack can send IPv6 packets, DAD + RS packets are seen in Linux host side.
• a101 does not receive any IPv6 packets, we see that the led blinks in the shield but the enc zephyr driver does not receive any packets meaning that the packets are dropped before the enc driver

We need to investigate next if the Linux is using proper MAC address when it sends the packet to a101 as if the MAC address is not correct, the packets would be dropped like what we are seeing.

[zephyrbot]

by Tomasz Bursztyka:

Tested on frdm k64f: works perfectly fine there.

So I confirm: if there is an issue on a101+enc shield, the enc shield (or the driver) are the problem.

[zephyrbot]

by jiequan wu:

Hi Tomasz, I try to test echo-server ipv6 on frdm k64f (ipv4 is fine). But It has the sample issue with a101. My test step as follows:

1. cd samples/net/echo_server
2. make pristine && make BOARD=frdm_k64f
3. copy zephyr.bin to MBED of frdm.
4. connect frdm k64f to host by lan.
5. set host ipv6 address $ sudo ifconfig eth0 inet6 add 2001:0db8::2/64
6. open the serial port.
7. press the reset button.
8. ping test $ ping6 2001:0db8::1 tcpdump output log: {code} tcpdump: listening on enx0023545c5714, link-type EN10MB (Ethernet), capture size 262144 bytes 17:09:08.313293 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::1 source link-address option (1), length 8 (1): 00:23:54:5c:57:14 0x0000: 0023 545c 5714 17:09:09.331022 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::1 source link-address option (1), length 8 (1): 00:23:54:5c:57:14 0x0000: 0023 545c 5714 17:09:10.355025 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::1 source link-address option (1), length 8 (1): 00:23:54:5c:57:14 0x0000: 0023 545c 5714 17:09:11.379288 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::1 source link-address option (1), length 8 (1): 00:23:54:5c:57:14 0x0000: 0023 545c 5714 {code}

[zephyrbot]

by Jukka Rissanen:

It seems that the shield is dropping IPv6 neighbor solicitation messages that the Linux host is sending. Linux uses multicast MAC address as a destination address and the shield seems to ignore those packets. There is nothing we can do in IP stack in this case. Perhaps it is possible to program the eth chip to accept these packets so I am assigning this issue to enc driver maintainer.

[zephyrbot]

by Ravi kumar Veeramally:

Attached pcap file.

[zephyrbot]

by Jukka Rissanen:

According to the datasheet, the eth chip has a destination address filtering which seems to be too tight in our case. See chapter 8.5 in http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf

[zephyrbot]

by ethan gao:

Tomasz Bursztyka Just to double confirm with you, do you mean that the IPv6 works perfectly with your FRDM-k64f ? If in that case, could you please kindly share your setting and your host IPv6 route table ? thank you ! we failed to ping neither the global nor the linkl-local address of FRDM?

BTW, I found the MAC address outputed from the UART is changed every time once I press reset of FRDM-k64f after I flash the echo-server sample, is this on purpose?

[zephyrbot]

by Tomasz Bursztyka:

The mac address in frdm is randomly generated, so yes it will change at every boot.

I retried. Usually I setup my linux environment before starting the board: then it works. If I do the other way round (i.e.: like you do, board start then linux setup). It does not.

So indeed there is something fishy here. On frdm that is. Can you create a ticket for it? This current ticket is for a101.

[zephyrbot]

by Paul Sokolovsky:

If this is in "Code review" state, where is the review? Nothing is shown in "Gerrit Reviews" section (I find Gerrit integration to be pretty unreliable).

[zephyrbot]

by jiequan wu:

I tested the latest commit, ping echo server ipv6 address is still unreachable.(commit id: acece24eacab30 branch: master)

[zephyrbot]

by Paul Sokolovsky:

(Unrelated to the previous comment.)

There's now https://jira.zephyrproject.org/browse/ZEP-1673 to track the issue of multicast reception control from IP stack level, and across different drivers/boards.

[zephyrbot]

by jiequan wu:

I tested the latest commit (161a863da715019b) on master , it works well.

[zephyrbot]

by jiequan wu:

The latest commit on master branch(commit id: e4aa74125c), this issue reproduces. And on v1.7.0 branch is ok. Maybe some patchs are missing in master branch.

[zephyrbot]

by jiequan wu:

The latest commit is fine(commit id: 1a9600b70 && master branch).

[zephyrbot]

Related to ZEP-1602