IPv6 ping fails using sample application echo_server on FRDM-K64F

[zephyrbot]

Reported by ethan gao:

Build and flash the sample application of echo_server to board frdm-k64f, and then setup your client in another host with IP address 2001:0db8::2/64, ping the static IPv6 address a.k.a 2001:0db8::1 of the board, but no response received from the board. fortunately, the IPv4 ping works. maybe it's more or less related to the issue in GH-3010, and here to just track this issue on FRDM-K64F separately.

(Imported from Jira ZEP-1602)

[zephyrbot]

by ethan gao:

Just copy Tomasz Bursztyka description here for reference, as follow:

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 ethan gao:

Tomasz Bursztyka I tried your workaround to setup linux host firstly and then flash the echo_server sample to start frdm-k64f, but it doesn't work yet. My procedure is as follows:
Boot-up my linux host and then
/* configure IPv4 address /
$sudo ifconfig enp14s5 192.0.2.2
/ configure IPv6 address /
$sudo ifconfig enp14s5 add 2001:db8::2/64
/ keep pinging the frdm-k64f IPv6 address */
$ping6 -I enp14s5 2001:db8::1
Then
clone the zephyr repo and step into sample echo_server:
run make pristine && make BOARD=frdm_k64f
next copy the zephyr.bin to the mass USB folder to let it flash into frdm.
Finally find a NW cable to directly connect the linux host and the frdm-k64f.
unfortunately, the IPv6 ping fails as usual from the linux host, so I kept reseting the frdm, but the failure persists. BTW, the ping to IPv4 works.

So I want to make clear whether this procedure is your "I setup my linux environment before starting the board", or something missed by me ? please help point out if in that case, thank you !

[zephyrbot]

by Paul Sokolovsky:

I confirm this issue. So far I wasn't able to get ping6 the frdm_k64f despite various "before" vs "after" steps, so would like to join in asking Tomasz for exact steps to get it working.

What I see in Wiresharks is:

95 480.915031000 2001:db8::2 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8::1 from 3c:97:0e:c8:94:35

packets which never get answered. Nothing is visible as received in net console stats either (but fairly speaking, even IPv4 pings aren't counted as received).

As it's FRDM's MAC address is what can't be resolved, that no IPv6 networking works at all. All that stuff definitely works in QEMU.

[zephyrbot]

by Paul Sokolovsky:

Actually, now IPv4 pings stopped working for me, board reset and power-offs don't help.

[zephyrbot]

by Flavio Santes:

I confirm this issue exists for IPv6, ping6 is not working.

On the other hand, IPv4 works after a hard reset is applied and the Ethernet cable is unplugged (before the reset) and plugged again (after the reset).

Last, I don't observe this issue on TCP/IPv6 client-mode applications, so perhaps this issue is related in some way to the server mode only.

[zephyrbot]

by Paul Sokolovsky:

Actually, now IPv4 pings stopped working for me, board reset and power-offs don't help

Over weekend, it cooled down and started working again, I didn't even have to reboot my laptop.

So, I proceeded with testing I wanted to do, and that's adding old good printf to eth_rx() in eth_mcux.c.

So, I do "ping 192.0.2.1", in Wireshark I see:

8	21.253887000	192.0.2.2	192.0.2.1	ICMP	98	Echo (ping) request  id=0x27d3, seq=1/256, ttl=64

And from board I get:

[dev/eth_mcux] [DBG] eth_rx: eth_rx: fr_len=98

Now I do "ping6 2001:db8::1", in Wireshark I see

195	337.188703000	2001:db8::2	ff02::1:ff00:1	ICMPv6	86	Neighbor Solicitation for 2001:db8::1 from 3c:97:0e:c8:94:35

And from the board I see - nothing, definitely no packet of size 86 gets received.

So, those pings, they go to multicast address ff02::1:ff00:1, and that needs to be added to multicast filters of the ethernet hardware, right? Is it being done properly?

[zephyrbot]

by Paul Sokolovsky:

Interface 0x20000e20
====================
TX stack size 1200/1296 bytes unused 588 usage 612/1200 (46 %)
Link addr : 00:04:9F:B4:9E:B6
MTU       : 1500
IPv6 unicast addresses (max 5):
	fe80::204:9fff:feb4:9eb6 autoconf preferred infinite
	2001:db8::1 manual preferred infinite
IPv6 multicast addresses (max 5):
	ff84::2
IPv6 prefixes (max 2):
	<none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 17525
IPv6 retransmit timer    : 0
IPv4 unicast addresses (max 1):
	192.0.2.1 manual preferred infinite
IPv4 multicast addresses (max 1):
	<none>
IPv4 gateway : 0.0.0.0
IPv4 netmask : 0.0.0.0

[zephyrbot]

by Paul Sokolovsky:

ENET_AddMulticastGroup() never called in eth_mcux.c.

Grepping for "cast" in zephyr/drivers/ethernet/ gives hits only for unicast and broadcast.

[zephyrbot]

by Paul Sokolovsky:

Last, I don't observe this issue on TCP/IPv6 client-mode applications, so perhaps this issue is related in some way to the server mode only.

Indeed, building echo_client (which lacks prj_frdm_k64f.conf) and running it, I can "ping6 2001:db8::1", but here's how it might work:

398	1998.658656000	2001:db8::1	ff02::1:ff00:2	ICMPv6	86	Neighbor Solicitation for 2001:db8::2 from 00:04:9f:93:2d:d6
399	1998.658686000	2001:db8::2	2001:db8::1	ICMPv6	86	Neighbor Advertisement 2001:db8::2 (sol, ovr) is at 3c:97:0e:c8:94:35

So, here FRDM actively sends Neighbor Solicitation, gets it reply, after which both FRDM and host are resolved to each other.

[zephyrbot]

by Flavio Santes:

Anas Nashif , Mark Linkmeyer , Andrei Laperie besides the common interest in having all the sample applications working as expected, it seems this issue is also affecting GH-2327.

Is there any update about this?

Regards,
Flavio

[zephyrbot]

by Anas Nashif:

this is high priority bug and must be fixed for 1.7, how does this affect http server sample exactly?

[zephyrbot]

by Flavio Santes:

I observe the same behavior here than in my other TCP/IPv6-server-mode applications.

[zephyrbot]

by Anas Nashif:

I am not sure I am following, how does ipv6 ping related to http server sample? Can you please specify what is going wrong with the http server that is related to this issue?

[zephyrbot]

by Flavio Santes:

It seems that ND on the FRDM board is not working for TCP/IPv6 in server mode. ping6 errors are just a consequence of this. However, I would like to see Comms feedback just to be sure we refer to the same issue.

[zephyrbot]

by Paul Sokolovsky:

Actually, now IPv4 pings stopped working for me, board reset and power-offs don't help.

Well, this is getting old. Just when I wanted to make a decisive test on this, I got this again. Actually, it wasn't just "no network communication to frdm_k64f", for few seconds my host completely froze as if under flood ping in old good days of Linux 1.2. So, apparently, frdm fights back. Plugging off eth cable fixed the freeze. For reference, e1000e driver is used on the host here.