Interoperability with TP-Link Range Extender

Libraries
1

We are facing an issue with our device’s inability to connect to TP-Link Range Extender (Models : RE200, RE220).
The device is currently using Amazon FreeRTOS v1.4.7 baseline with FreeRTOS TCP/IP stack.
The device is an ESP32WROOM32E module from Espressif.

A very high level analysis of this issue on our end, it seems the FreeRTOS device is not able to obtain an IP Address when using the TP-Link Range Extender and hence the failure to establish a connection.

2

A couple of preliminary questions to narrow down possible sources:

  1. Have you tried connecting to the TP-Link from a basic project that doesn’t contain any code other than that necessary to connect? So, from outside of FreeRTOS, or before FreeRTOS is started? If so, were you able to connect successfully?

  2. Are you able to take a trace of the communications using something like AirPCap?

3

Hello @pbansal,

The below solution might work for you.

Some background on the issue:
I have seen one such similar issue earlier as well due to the range extender stripping off UDP checksum and causing packet drop by FreeRTOS+TCP device.

You said that “the FreeRTOS device is not able to obtain an IP Address”. Yes, that sounds about right. The TCP device uses DHCP to try and obtain an IP address from the DHCP server. DHCP runs on top of UDP layer. If the range extender is stripping the UDP checksum (and replacing the checksum with 0), then the response from the DHCP server will be dropped by the FreeRTOS+TCP device.

The resolution:
Due to security concerns, a macro was introduced ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS which allows the user to choose whether to accept UDP packets with 0 checksum or to drop them. The configuration defaults to 0 - meaning drop packets.
You can add this line to the local copy of FreeRTOSIPConfig.h file: #define ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS 1 to fix this issue.

Let me know if this works for you!
If not, we can dive deep into the issue and try to find a resolution. In this case, please provide answers to the questions that Richard has posted above. I’ll ask you a few more questions too :slight_smile:

Regards,
Aniruddha

4

Hello @kanherea,
We looked for the ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS macro. It seems this was introduced in FreeRTOS+TCP v2.3.0
The FreeRTOS+TCP we use is v2.0.10 which does not have this macro.
This is a bit old release from Amazon FreeRTOS v1.4.7.
Pls suggest other options we can do.

Regards,

5
  1. Have you tried connecting to the TP-Link from a basic project that doesn’t contain any code other than that necessary to connect? So, from outside of FreeRTOS, or before FreeRTOS is started? If so, were you able to connect successfully?

We are using the FreeRTOS+TCP to obtain the IP address after connection. Without FreeRTOS+TCP we will not be able to establish a successful connection.

  1. Are you able to take a trace of the communications using something like AirPCap?

We do not have a sniffing tool available to capture packets in air.

6

We looked for the ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS macro

In earlier versions, UDP packets with a zero checksums were received, so that can not cause the problem.

Do you see any other communication? Does ARP work? Does ping work?
Can you step through the code and put break-points?

7

Hello,

I looked at the publically available documents of the TP-Link range extender but could not find anything there which I could use to determine the issue.

As @htibosch said, can you step through the code? And can you see any other form of communication happening? Can you use Wireshark on the same network to see the DHCP packets (not sure about this but mostly it’ll be able to capture the broadcasted data over wifi)?

Regards

8

Hi Prashant,

  1. While we at FreeRTOS work on replicating the issue, and/or verifying that our newer versions do not contain the issue, by procuring and setting up a TP-Link device, could you and your team provide us with either a wireshark (or equivalent) capture and/or logs to help us diagnose the problem better.
  2. In your correspondence you have mentioned that you did try out the solution proposed by tokuj@ which was to follow the resolution for a very similar issue - ESP32 cannot connect to TPLink TL-WA855RE Wifi Extender (IDFGH-1853) · Issue #4060 · espressif/esp-idf · GitHub Could you care to expand upon what steps were taken? Did your team cherry pick this commit Deadlock @ mdns_free() (IDFGH-718) · Issue #1696 · espressif/esp-idf · GitHub or this one Fix DHCP option Client-identifier by shubhamkulkarni97 · Pull Request #1696 · aws/amazon-freertos · GitHub ? Both are #1696 but according to the customer in ESP32 cannot connect to TPLink TL-WA855RE Wifi Extender (IDFGH-1853) · Issue #4060 · espressif/esp-idf · GitHub he had used Deadlock @ mdns_free() (IDFGH-718) · Issue #1696 · espressif/esp-idf · GitHub

Thanks,
Toshi

9

Hello @pbansal,

A short update:
I tried using the latest head of amazon-freertos with the FreeRTOS+TCP stack on esp32 and a nuvoton board with and without a TP-Link RE220 range extender. It seems to work well for me (ignoring a few build issues that I had to fix). I used the default MQTT demo to test it. It published “Hello world” successfully.

I shall now checkout the versions of FreeRTOS and FreeRTOS+TCP that you are using and I shall try that too with the range extender. :slight_smile:

Did you get any usable Wireshark capture that we can use?

Regards

10

Hello @pbansal,

I was able to replicate the issue you were having with the old version of amazon-freertos and FreeRTOS+TCP you are using. The DHCP would not complete the whole process of Discover,Offer,Request,Acknowledge. It just completed the first 3 steps but never got an ACK from the DHCP server.
That was due to the fact that the DHCP message fields were not placed correctly. They were off by one byte.

Do note that this bug was already fixed a while back in the FreeRTOS+TCP repository and the latest version works perfectly without a glitch.

You can try making the changes as seen in this diff.

Let me know if that works for you.

Regards