Open qjy0129 opened 9 months ago
Additional information This was first discovered in your other projects https://github.com/espressif/esp-hosted/issues/289
Is there still someone in your company investigating this issue? I haven't heard any news for a long time.
Please attach sniffer capture.
This involves message/packet capturing:https://github.com/espressif/esp-hosted/issues/289 Can't this issue be reproduced internally by your team? It seems to be relatively easy to reproduce.
Please do a capture over the air instead of capturing at different places.
Can you take a careful look at the previous analysis process? https://github.com/espressif/esp-hosted/issues/289 At the same time,I will re-capture the packet.
Re-captured the packet. Esp32 run wps_softap_registrar example. The message was captured on a laptop, which was connected to the eps32 hotspot via wireless. By filtering DHCP messages, it was found that there were two consecutive DHCP Discovery messages sent. Within the first two seconds timeout, no DHCP Offer message was received, so it was re-sent again. This is likely caused by the eps32 air interface losing the Offer message. esp32.txt Due to upload attachment limitations, the esp32.txt needs to be renamed to esp32.pcapng so that it can be opened via Wireshark
Hi @qjy0129, these packets are captured on wired interface on station which doesn't give full picture. Could you please try to capture packets on a spare linux wifi system.
Linux:
sudo ifconfig
Also please disable your network manager before doing this.
esp32_cap.tar.gz After decompressing the attachment, you can view the complete packet using the Wireshark tool.
Is it difficult for you to reproduce this issue on your side? I feel that it should be easily reproducible. https://github.com/espressif/esp-hosted/issues/289 In this discussion, your other team has also reproduced this issue.
@jgujarathi Hello, has there been any progress on this issue? If so, could you please inform me?
Hi @qjy0129 , We are analysing the issue actively. We will get back to you with any updates.
Hi @qjy0129 , We have tried reproducing the issue. While there are multiple DHCP requests sent by the station in the sniffer captures only a few are actually acknowledged by our wps softap registrar device. The acknowledgement implies that it is received by our Wi-Fi stack. In our experiments we have noticed that every DHCP Request that has been acknowledged is passed down to the DHCP server , a corresponding DHCP ACK/NAK is sent out and is visible in the sniffer capture. This means that the other DHCP packets you see are dropped in the air and not by the esp32 device. This can be due to several factors involved in wireless networking.
Please find attached a sample sniffer capture on our end. example.zip In this example there are 5 DHCP requests sent out but only 2 are actually acknowledged by our device. There are 2 corresponding DHCP ACKs as a result. Please add the decryption keys by following https://wiki.wireshark.org/HowToDecrypt802.11. (wpa-pwd -> mypassword:myssid). The station has the mac address 3e:8b:cc:08:d9:c0.
If you come across a case where the wps softAp registrar has acknowledged a DHCP Request and not generated a DHCP Ack/NAK please provide us with a sniffer capture and debug logs.
Hi @jgujarathi https://github.com/espressif/esp-hosted/issues/289 In this discussion, it has been clarified through log additions that the packets are being dropped at the esp esp_wifi_internel_tx interface.
In addition, run esp-idf/examples/wifi/iperf test case: On the esp32, execute the command:
ap test 12345678
Connect the laptop to the 'test' hotspot, and it acquires an IP address of 192.168.4.2. On the laptop, execute the command:
iperf -s -u -i 1
Then on the esp32, execute the following command:
iperf -c 192.168.4.2 -u -b 1 -i 1 -t 9999
From the iperf results on the laptop, packet loss is observed, even at a rate of 1Mbps. Have you guys used your esp's Wi-Fi module in commercial applications, or is it only suitable for personal DIY projects?
Hi @qjy0129, We hope you understand that in wireless networking there is always a possibility of dropping packets due to several factors that do not exist in wired mediums. When the rate is limited to 1mbps, it is impossible to achieve that rate in a real world environment due to several reasons for interference. Several APs and devices using the same medium can cause contention issues and it is quite tough to get the slot to send out packets, especially for the amount of time that bigger packets iperf uses will require. There are additional factors that can cause even more drop in rate, such as the RX capabilities of the intended target, it's buffer sizes and it's configuration. In my previous comment I have attached sniffer captures in which we have measured that every DHCP message sent from the DHCP server does actually make it into the air (sent through esp_wifi_internal_tx). I am attaching further logs of a iperf throughput test we conducted following your steps but in a relatively quiet environment and were able to achieve near perfect 1mbps throughout the test. throughput_quiet_env.txt
Hi @jgujarathi , Thank you very much for your response. When ESP32 sends messages through esp_wifi_internal_tx interface, what device do you use to capture the packets transmitted over the air? Currently, it seems that the issue might be due to either the antenna on my ESP32 development board or the Wi-Fi functionality of my laptop not functioning well?
Hi @qjy0129 , We use a Linux desktop with it's wireless interface set in monitor mode. Please refer to this comment for the recommended setup.
Answers checklist.
IDF version.
v5.0.4-319-ga6afbb38a4
Espressif SoC revision.
esp32
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
esp32-wroom-32e
Power Supply used.
USB
What is the expected behavior?
laptop wifi requests a dhcp request, and an esp32 hotspot returns a dhcp ack message
What is the actual behavior?
Laptop wifi DHCP request multiple times and the DHCP ack message replied by ESP32 are not equal. From packet capture analysis, it can be seen that EPS32 responds less to DHCP ack messages.
Steps to reproduce.
Debug Logs.
More Information.
No response