-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP-Hosted-FG: wifi ap packet loss issue #289
Comments
Hello @qjy0129 , The overTheAir captures or sniffers may drop the packets and sniffer is expected to work for whole channel. Also, please bear in mind, Wireless medium heavily depends upon the signal strength, contention, noise level, saturation etc. Let us know if you have any drop seen on ESP-Hosted as such (Host to slave Or other way round), which is basically transport (and wired). |
The physical connection is shown in the figure. The laptop is wirelessly connected to ESP32 and dynamically obtains the IP address. When using Wireshark to capture the DHCP message on the laptop, it is found that there is an issue with protocol interaction. The dhcp ack message from STM32 is sent to ESP32 through SDIO, and ESP32 successfully obtains the dhcp message. However, ESP32 sends it through the interface esp_wifi_internel_tx and the packet capture tool on the laptop does not catch it ESP32 calls esp_wifi_internel_tx interface code: esp log: in esp32.log sdio_receive hexadecimal report printed through Wireshark analysis: DHCP related messages captured on the laptop: Through packet capture comparison, the laptop did not receive the DHCP ack message sent by ESP32 esp_wifi_internel_tx |
Sorry I could not check this today, Will test this and get back in a couple of days. if you get response but dropped in memcmp below? |
add print, get response not dropped in memcmp below。 There is no problem with the SDIO transmission between ESP32 and STM32, and the messages sent by the laptop can also be received by ESP32. However, ESP32 sends the messages to the laptop through the interface esp_wifi_internel_tx, and the corresponding messages are not captured by the laptop |
Instead of capturing packets on laptop interface, |
Also, do you see response ? Is it DHCP ack in #289 (comment) |
I also had this issue when testing with a mobile phone instead of a laptop
I see DHCP ACK response |
Oh okay. Can you please send For example,
I want to check what crystal frequency you use. |
If crystal is fine, we still would need esp verbose logs along with wpa logs enabled, along with host logs and sniffer capture which need to be started before the connection. I will add details how esp logs can be collected. |
esptool.py v4.7.dev2 Printing can only be debugged. If open verbose eps32 system will constantly restart。 laptop capture: esp32log: The memory usage of the compiled bin may be helpful for analyzing problems |
Thanks for adding / removing logs at expected places and debug logs. Instead of captures taken at ESP and laptop etc separately, can you take a sniffer capture from start (with EAPOL M1->M4 captured)? |
Obviously, the messages of DHCP should just transparently be passed to network interface or Wi-Fi driver by ESP-Hosted. Also, Can you please check assign static address manually and the ping work from one station to other station connected to same AP? Please note, For station to station communication, please comment the memcmp lines from earlier discussion. |
We have already captured DHCP offer or ack messages on ESP32, indicating that there is no problem with the DHCP server. In addition, our device also has a wired Ethernet interface, so there is no problem with assigning addresses. Just using the dhcp protocol to illustrate that your ESP32 wifi interface esp_wifi_internel_tx will lose packets |
We will verify the DHCP server with the softAP using Linux host. We will capture logs (including sniffer) at our side and test your scenario. |
esp-idf/examples/wifi/wps_softap_registrar Repeatedly connecting to the EPS32 hotspot with a laptop will reproduce the problem |
if you see this getting reproduced on ESP-IDF also, you can directly raise this issue at ESP-IDF issues. We will also check internally, but creating issue at ESP-IDF would get faster response. |
@qjy0129 We have tested the DHCP server with the ESP32 as Hosted softAP using Linux host and did not encounter issues. Our hardware setup:
To capture packets as seen by the ESP32 softAp, debug code was added to SoftAP setup on Raspberry Pi with ESP32:
Running the test:
Attachements: Log file from the ESP32 running as softAP, from the moment the station connects to it, followed by the various pings, to cross-reference against the pcap capture (see below) pcap file captured showing the traffic between the softAP and the station. You can use Wireshark to open the pcap file and set it to decrypte the data by following the steps here https://wiki.wireshark.org/HowToDecrypt802.11 You can use the display filter to see the |
Let us know once you raise the issue at ESP-IDF.. |
I raise the issue at ESP-IDF: |
Is there still someone in your company investigating this issue? I haven't heard any news for a long time. |
@qjy0129 sorry let me check this with someone in Wi-Fi team for you. |
ESP32 receives network messages from the main control through SDIO and sends them through esp_wifi_internel_tx(ESP_IF_WIFI_AP, payload, payload_len) sends messages, and the content of payload is printed out through logs. However, when a wireless device uses Wireshark to capture packets, it is found that the received messages are fewer than those sent by ESP32 wifi. Why does the interface esp_wifi_internel_tx have a probability that messages are not sent properly?
The text was updated successfully, but these errors were encountered: