Difference between Ethernet and Wifi for receiving UDP packet just after sending

[ShaunWesty]

Hello,
What am I doing wrong?
I am using a tweaked version of the UDP client and UDP sever code.
https://github.com/espressif/esp-idf/tr ... udp_client
https://github.com/espressif/esp-idf/tr ... udp_server

I have the udp_server code running as a Task (as in the example) receiving everything hitting port 17288. It then prints the message received.
I have the udp_client code running as a single function triggered from a timer every 8 seconds. The client code performs the sendto() but it does not try to receive anything, it closes the socket after the send.
I have another piece of hardware that is broadcasting a message [1] as well as listening for the ESP32. When it receives the message [2] from the ESP it responds with a new message [3]. (Numbering the messages for future)
The Problem:
When I configure the ESP32 to only use a Wifi connection to my network, the response[3] is seen by the ESP32.
When I configure the ESP32 to only use an Ethernet connection to my network, the response[3] is NOT seen by the ESP32.

I have used a hub and wireshark to confirm the messages are traveling the network. The only difference between the messages in Wireshark is the IP address is different for the Wifi/Ethernet connections.
I have also confirmed that the ESP32 is correctly receiving the response[3] if it is sent from a different source (virtual box netcat) however this is just sent at a random time, not immediately after the ESP32 sends it.

I also tested just using the UDP client (no server) with the receive code in... waiting for 1 second before moving past the recvfrom(sock...) code. Again this did not work for Ethernet, but it did for Wifi.

If you need me to post the code I am using, I can.

Shaun

[ShaunWesty]

Figured it out mostly. The reply is coming back to the ESP32 within 3ms which the hardware cannot process.
What I do not know is what hardware is having the difficulty. It is either the LAN8720 or the ESP32.
Need a scope on the RX lines to see if the message is actually transferring from the LAN chip towards the ESP32 and it is not getting processed/dropped.

[ShaunWesty]

So I was completely wrong.
The issue was with the MAC address I was transferring to the other device in the UDP payload. I was not accounting for the esp_mac_type_t of the connected interface (ESP_MAC_ETH) as I was just using the esp_efuse_mac_get_default() function instead of calling esp_read_mac() with the ESP_MAC_ETH parameter. Obviously I could have just using esp_efuse_mac_get_default and add the ESP_MAC_ETH to the last octet, but .

The device I was talking to cannot easily pull the IP and MAC out of its stack (which is why it is included in the UDP payload), so when it sent back it was sending to the correct IP, but not the correct MAC.

Job done, Latency measurements are generally less than 3ms.

Wireshark Data that pin-pointed it (after having one of those... hang on a minute I thought I read something... moments)
Poll:
Destination: PaktonTe_02:af:1a (c8:90:3e:02:af:1a)
Source: Espressi_83:bf:6b (24:0a:c4:83:bf:6b)
Response:
Destination: Espressi_83:bf:68 (24:0a:c4:83:bf:68)
Source: PaktonTe_02:af:1a (c8:90:3e:02:af:1a)