frdm_k64f: Ethernet networking starts to respond ~10s after boot

[zephyrbot]

Reported by Paul Sokolovsky:

As reported "by the way" in few other tickets, frdm_k64f Ethernet networking doesn't respond immediately after boot, it takes some time for it to start responding to pings, etc. I just timed it after one particular reboot to be ~10s.

I don't remember such long delay before https://gerrit.zephyrproject.org/r/#/c/11176/ . (But can't pledge there wasn't a shorter, 1-2s delay before it.)

(Imported from Jira ZEP-1734)

[zephyrbot]

by Paul Sokolovsky:

I just has a case when IPv4 pings already responded, while IPv6 didn't, and started to respond in ~2s.

[zephyrbot]

by Paul Sokolovsky:

Pressing Reset and starting ping at the same time. As can be seen, IPv6 indeed has longer median bootstrap time.

# ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=9 ttl=64 time=0.805 ms
64 bytes from 192.0.2.1: icmp_seq=10 ttl=64 time=0.290 ms

# ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=10 ttl=64 time=0.789 ms
64 bytes from 192.0.2.1: icmp_seq=11 ttl=64 time=0.411 ms

# ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=13 ttl=64 time=0.751 ms
64 bytes from 192.0.2.1: icmp_seq=14 ttl=64 time=0.437 ms


# ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=9 ttl=64 time=0.562 ms
64 bytes from 2001:db8::1: icmp_seq=10 ttl=64 time=0.273 ms

# ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=20 ttl=64 time=0.553 ms
64 bytes from 2001:db8::1: icmp_seq=21 ttl=64 time=0.452 ms

# ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=20 ttl=64 time=0.595 ms
64 bytes from 2001:db8::1: icmp_seq=21 ttl=64 time=0.353 ms

[zephyrbot]

by Mark Linkmeyer:

Hi Maureen Helm , can you help set the priority of this bug? If it's determined to be a high or medium priority, we'll need someone assigned to it also to help get the bug count down. Thx!

[zephyrbot]

by Paul Sokolovsky:

Until Maureen Helm responds, let me just say that I created this ticket to collect in one place information mentioned "by the way" in other tickets, and collect more evidence to resolve it eventually. I don't think it's a serious issue, and wouldn't think it's resolved for 1.7. So let me set it to Low.

Note that further investigation may show that it noticeably affects client-side applications running on frdm_k64f (like, they don't work, because they're not ready to handle "network isn't up at startup" situation), and priority can be increased. But let that be explicit decision.

[zephyrbot]

by Maureen Helm:

Agree to set it to Low for now. Thanks Paul Sokolovsky for all your work on the frdm_k64f ethernet.

[jukkar]

Closing old bug.