802.11 refragmanation isn't actually working (IDFGH-11017)

[razgino11]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

master / develop both checked

Operating System used.

Windows

How did you build your project?

Other (please specify in More Information)

If you are using Windows, please specify command line type.

None

Development Kit.

Esp32 Wrover

Power Supply used.

USB

What is the expected behavior?

Im receiving a video stream from a drone in udp, the packets aren't fragmanted on the ip layer or the udp layer, but they are consisting of fragmanation on the 802.11 layer, which espressif claims is supported on receving on both esp32 and esp8266

What is the actual behavior?

fragmanated packets are not received, under any sdk they are dropped, only packets that are not fragmanted on the 802.11 layer are received

Steps to reproduce.

1. Send fragmanated 802.11 packets (in my case they are udp packets fragmanted into 2/3 fragments)

Debug Logs.

No response

More Information.

Im using platform io to build, with multipule idf version tried, also tried on the esp8266 to no luck, also wrote the software in arduino with the same problem

[mhdong]

Hi @razgino11
Have you enable LWIP_IP4_REASSEMBLY and LWIP_IP6_REASSEMBLY? If not, you can enable it by menuconfig.
idf.py menuconfig->Component->LWIP->Enable reassembly incoming fragmented IP4 packets.

[razgino11]

@mhdong yes, and it's not the issue, I'm talking about 802.11 layer fragmantion, not ip layer

[mhdong]

Hi @razgino11
Okay, we will try to reproduce it as soon as possible and fix this issue. If it's convenient, you can upload the log and packet capture during reproduction.

[razgino11]

tello udp capture (1).zip

I have put my network card in monitor mode and captured from the relevant channel, from around the middle point you can see there are fragmanated 802.11 frames sent in mostly groups of 3, and in the and of each, a udp packet which consists of the put togheter packet (if you will view it using wireshark for example)

on the 802.11 layer you could see the fragment number each, only the packets which are not fragmanted (480 bytes or less) are received on the esp

i have tested this with: esp8266, esp32, esp32-s3 and the problem presists on all of them
couldn't test it yet with my esp32-c6 since i couldn't get the receiver code to work yet,

also tested on raspberry pi pico to make sure the problem isn't with the sender, and the data received just fine

the data is the recorded video stream from the dji tello drone which is very cheap if you want to preform live testing

Thank you for your help, and let me know if i can assist in any way further :)

[MaxwellAlan]

Hi @razgino11

Could you give us a IDF commit? we can base your IDF version to give you a patch with debug log to look into this issue.

BTW, could you test this case with WPA/WPA2 encryption mode?

Thanks.

[razgino11]

@MaxwellAlan
Im using platformio so my idf is straight from: https://github.com/platformio/platform-espressif32
for the boards esp8266, esp32, esp32-s3 (tried them all)

I have tried with WPA encryption mode as you said and the problem was solved!
can you provide insight on why you think that may have solved it?

you can stilll send over the debug version if you guys need help debugging this

[MaxwellAlan]

@razgino11
Thanks for the important debug info, we have found the root cause and fixed internal, please wait for the code sync to github.

[mhdong]

Hi @razgino11 fix on master branch is available at c84b2cb, Thanks.

[AxelLin]

Hi @razgino11 fix on master branch is available at c84b2cb, Thanks.

@mhdong
According to #12201 (comment),
this issue impacts esp8266, esp32, esp32-s3 .

But above commit only fixed esp32c3 and esp32s3.
Could you clarify if esp32 is fixed?

[mhdong]

Hi @AxelLin This commit change is valid for all chips except for ESP8266. Only ESP32C3 and ESP32S3 involve rom code, and related functions need to be annotated. ESP8266 involves another project, and we will complete the relevant fix as soon as possible, Thanks.

[AxelLin]

@mhdong

v5.2 branch : 89dcaf4
v5.0 branch : 5402e14
But I cannot find the fix in v5.1 branch?

[mhdong]

Hi @AxelLin The backport for v5.1 is not yet completed. We will backport it to v5.1 as soon as possible.

[mhdong]

Hi @AxelLin @razgino11
Fix on v5.1 branch is available at b3c7123.