search

zephyriot / zephyr-issues

0 stars 0 forks source link

echo_server with DTLS drops lots of packets on frdm_k64f #2412

Open nashif opened 7 years ago

nashif commented 7 years ago

Reported by David Brown:

The attached patch enabled TLS/DTLS in the {{samples/net/echo_server}} app (the ip addresses at the end will need to be adjusted to the local network). You can also build the net-tools package (the dtls-client.c source needs to be edited for the client addresses).

I used wireshark to capture traffic, but running the dtls-client is able to communicate with this echo server. However, a significant number of packets don't seemed to be received by the device, and the test takes quite a long time. {{wireshark -f 'udp port 4242'}} is good for capturing this, and there are clear 1-second pauses with re-transmissions.

(Imported from Jira ZEP-2582)

nashif commented 7 years ago

by David Brown:

nashif commented 7 years ago

by Mark Linkmeyer:

Andrei Laperie , please set the priority of this bug. Thx.

nashif commented 7 years ago

by Aska Wu:

David,

Some questions:

  1. Which kind of address does dtls client and echo server use? ipv4 or ipv6?
  2. Do you run "dtls-client -e" to send and receive data "forever"?
  3. How do you know that some packets are not received by the device? Do you mean that echo server doesn't response the client packet?
  4. According to my test, dtls client sends packet to the device, but it takes a long time, e.g. 19 seconds, for echo server to response the packet. Despite the delay, the packet is send and received correctly.

Thanks

nashif commented 7 years ago

by David Brown:

Both IPv4 and IPv6 should work, with the given config file. I sometimes found IPv4 to not work with IPv6 enabled.

I just ran dtls-client, without options. Either should work, though.

I used wireshark to watch the traffic. It is easy to see some pauses (typically one second) where the client sends a packet, there is a delay, and then it resends.

The long time is because the packet is dropped and the client retries. There are a bunch of packets going back and forth (which wireshark should show), and the long time is because the server doesn't get or doesn't respond to many of the packets.

You can also reconfigure dtls-client to talk to a localhost dtls-server to see how it is expected to work. It is also possible to use openssl as the dtls-client, although I found it to not successfully complete:

$ openssl s_client -connect ipaddr:4242 -dtls

not sure how new of an openssl is needed to have dtls support. The ipaddr should be the ipv4 or ipv6 address of the Zephyr target. Openssl has the advantage of being fairly verbose. When it is finally working, you should be able to type lines and have them echoed back.

nashif commented 7 years ago

by Aska Wu:

David, Thanks for the explanation.

nashif commented 7 years ago

by Aska Wu:

Update:

Wiresharks shows that the packet has been sent to echo server, but ethernet driver (eth_mcux.c) doesn't call net_recv_data() immediately. net_recv_data() is not called until couple of new packets arrived. This cause the delay.

By setting CONFIG_ETH_MCUX_RX_BUFFERS=1, I cannot reproduce the delay issue. net_recv_data() is called immediately when any new packet is arrived.

David, can you try the rx buffer setting and see if it works on your side? I have no idea why I don't need to tweak the rx buffer parameter when running other samples. And I think it's related to the ethernet driver, should I assign this ticket to guys from NXP for further investigation?

nashif commented 7 years ago

by David Brown:

I'll be able to try this on Tuesday when I'm back to work (Mon is a US holiday).

Having to reduce buffers is definitely a bug. I suspect it is caused, some how, by enabling TLS/DTLS. I would suggest an email to the zephyr list, possibly "To" some key MCUX eth people, pointing to this ticket, and see if they have any thoughts.

It might be worth digging into what is happening when there are two buffers, and how that could be causing the packet to be missed.