search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.44k stars 7.25k forks source link

ESP32 cannot connect to TPLink TL-WA855RE Wifi Extender (IDFGH-1853) #4060

Closed bgintz-rsc closed 4 years ago

bgintz-rsc commented 5 years ago

Environment

Problem Description

ESP32 cannot connect to TPLink TL-WA855RE Wifi Extender

Steps to repropduce

  1. Provision the ESP32 to connect to an AP without the TP-Link powered on.
  2. Configure the TPlink to extend the above network with the same SSID and Password and power on
  3. Reboot the ESP32 - it will fail to connect
  4. Remove the tplink from power
  5. Reboot the ESP32 it will connect
  6. Power on the TPlink extender
  7. Confirm that other devices in proximity to the extender can join the network.
negativekelvin commented 5 years ago

AmazonFreeRTOS 2019-6.00 seems to be based on esp-idf v3.1.3. Have you tried the station example from some of the esp-idf master or release branches to see whether it has been fixed by a recent update? Do you have a log or sniffer capture of the failure?

bgintz-rsc commented 5 years ago

Thanks for the reply. I do not have a log or sniffer capture. When I have a chance I can try to use one of the demos in the latest IDF.

bgintz-rsc commented 5 years ago

I retested using the ESP-IDF iperf examples on version 3.1, 3.3 and 4.4 and have not been able to replicate the issue unless I am using AmazonFreeRTOS. Are you able to build the AFR sample demo apps?

mahavirj commented 4 years ago

@bgintz-rsc Recently we have update IDF release to v3.1.5 in AFR. Can you please retry with latest Amazon FreeRTOS codebase (since it is not reproducible with release/v3.1, I think issue should have been fixed)?

bgintz-rsc commented 4 years ago

Thanks! I will do that. We are about to do a pre-release based on AFR 2019-06. Can I simply replace the $AFR_ROOT/vendors/espressif/esp-idf folder or do I need to update to a later AFR revision?

mahavirj commented 4 years ago

@bgintz-rsc Please consider updating to latest AFR revision (probably there is no release yet, post 2019.08, hence you will have to try with their master branch)

bgintz-rsc commented 4 years ago

Hello mahavirj

I updated our app to 20109.08 master commit df8d0e2f from yesterday and still not able to connect.

mahavirj commented 4 years ago

@bgintz-rsc

bgintz-rsc commented 4 years ago

Here is my pdf log message Mahavir: it is in

image

It is the same as you referenced:

image

mahavirj commented 4 years ago

@bgintz-rsc Did you missed out on attaching detailed debug logs? If you would like you can also send it across at mahavir at espressif dot com (I suspect that it could be some issue in WiFi abstraction layer in AFR, since you are unable to reproduce it with release/v3.1 IDF branch, hence I may need additional information like credentials, security type of extender etc.)

bgintz-rsc commented 4 years ago

Hello Mahavir,

We have extensive debug information in our logs at the moment. I am going to try this using one of the demos provided by AFR in the release above and see if that also fails I will send logs from that effort. I may not get to this for a few days however. The extender is being used with an xfinity (Comcast) router that has WPA2-PSK authentication. The extender is TPLink TL-WA855RE

bgintz-rsc commented 4 years ago

Hello Mahavirj,

So I built aws_demos (MQTT demo default enabled) with hardcoded wifi credentials. The extender was configured to create an extended network with the SSID: GINTZ07_EXT. The ESP32 connects to the extender but does not receive an IP address Assigned event in the event loop. The extender however indicates that it has assigned the device an IP address:

Here is the log:

image

negativekelvin commented 4 years ago

Well freertos ip stack is different from lwip used by esp-idf so you might get better help by continuing the issue on their repo

mahavirj commented 4 years ago

@bgintz-rsc

Can you please help with one more experiment, i.e. to try with PR at (https://github.com/aws/amazon-freertos/pull/1519) and build application with -DAFR_ENABLE_LWIP=1 which will enable lwIP networking stack? Just trying to narrow down issue (this is not related to WiFi stack), and then we can follow up accordingly with AFR team.

bgintz-rsc commented 4 years ago

I have not been able to try the above test but I do have some additional information to share. As mentioned previously the failure is due characterized by "The ESP32 connects to the extender but does not receive an IP address"

We have been doing some interoperability testing with an independent lab and asked for their analysis. They have reported:

"Typically, the DHCP offer from the DHCP server is a unicast. But with the range extender, the DHCP offer is a broadcast message."

This confirms that the TPLink extender is indeed assigning an IP address but the ESP32 is not recognizing it (and therefore no event is triggered in the ESP32 event loop).

Perhaps the ESP32 driver/stack is not recognizing the IP address assignment because it is a broadcast message. I do not currently have the router and will not be able to replicate the issue as requested until I do receive it.

bgintz-rsc commented 4 years ago

mahavirj

I had loaned my TPLink extender for testing and now have received it back. There does not seem to be anything in the AFR repo (or esp-idf) that I found which references AFR_ENABLE_LWIP as a preprocessor define. Where is this used please?

negativekelvin commented 4 years ago

https://github.com/aws/amazon-freertos/commit/2733e906629a70af9ba58067e4b7d781eed1385e

mahavirj commented 4 years ago

@bgintz-rsc In addition to above reference pointer provided by @negativekelvin, you may also refer to https://docs.aws.amazon.com/freertos/latest/userguide/getting_started_espressif.html#build-and-run-example-espressif for full command to build with lwIP networking stack. If you still observe issue, please do post complete console log here.

bgintz-rsc commented 4 years ago

Hello and Happy New Year Mahavirj!

I finally got the TPLink back and a chance to test this using LWIP. This should be easy for you to reproduce.

Test Conditions

Hardware

Results

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:7176 load:0x40078000,len:12620 load:0x40080400,len:6708 entry 0x40080778 I (73) boot: Chip Revision: 1 I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0 I (39) boot: ESP-IDF 2nd stage bootloader I (39) boot: compile time 15:00:14 I (39) boot: Enabling RNG early entropy source... I (43) boot: SPI Speed : 40MHz I (47) boot: SPI Mode : DIO I (51) boot: SPI Flash Size : 4MB I (55) boot: Partition Table: I (59) boot: ## Label Usage Type ST Offset Length I (66) boot: 0 nvs WiFi data 01 02 00010000 00006000 I (74) boot: 1 otadata OTA data 01 00 00016000 00002000 I (81) boot: 2 phy_init RF data 01 01 00018000 00001000 I (89) boot: 3 ota_0 OTA app 00 10 00020000 00177000 I (96) boot: 4 ota_1 OTA app 00 11 001a0000 00177000 I (103) boot: 5 storage WiFi data 01 02 00317000 00010000 I (111) boot: End of partition table I (115) boot: ota rollback check done I (120) boot_comm: chip revision: 1, min. application chip revision: 0 I (127) esp_image: segment 0: paddr=0x00020020 vaddr=0x3f400020 size=0x1d13c (119100) map I (178) esp_image: segment 1: paddr=0x0003d164 vaddr=0x3ffbdb60 size=0x02c70 ( 11376) load I (182) esp_image: segment 2: paddr=0x0003fddc vaddr=0x40080000 size=0x00234 ( 564) load I (185) esp_image: segment 3: paddr=0x00040018 vaddr=0x400d0018 size=0x7f584 (521604) map I (376) esp_image: segment 4: paddr=0x000bf5a4 vaddr=0x40080234 size=0x001cc ( 460) load I (377) esp_image: segment 5: paddr=0x000bf778 vaddr=0x40080400 size=0x102e4 ( 66276) load I (420) boot: Loaded app from partition at offset 0x20000 I (420) boot: Disabling RNG early entropy source... I (421) cpu_start: Pro cpu up. I (424) cpu_start: Application information: I (429) cpu_start: Project name: aws_demos I (434) cpu_start: App version: 201912.00-2-g3c89631c5-dirty I (441) cpu_start: Compile time: Jan 6 2020 15:00:13 I (447) cpu_start: ELF file SHA256: c5ac21db65659ab1... I (453) cpu_start: ESP-IDF:
I (458) cpu_start: Single core mode I (462) heap_init: Initializing. RAM available for dynamic allocation: I (469) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (475) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (481) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (487) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM I (493) heap_init: At 3FFC7F60 len 000180A0 (96 KiB): DRAM I (500) heap_init: At 3FFE0440 len 0001FBC0 (126 KiB): D/IRAM I (506) heap_init: At 40078000 len 00008000 (32 KiB): IRAM I (512) heap_init: At 400906E4 len 0000F91C (62 KiB): IRAM I (518) cpu_start: Pro cpu start user code I (201) cpu_start: Starting scheduler on PRO CPU. 0 1 [main] Initializing FreeRTOS TCP stack I (225) PKCS11: Initializing NVS partition: "storage" E (245) PKCS11: failed nvs get file size 4354 0 1 4 [main] Write certificate... 2 16 [iot_thread] [INFO ][DEMO][160] ---------STARTING DEMO---------

3 16 [iot_thread] [INFO ][INIT][160] SDK successfully initialized. I (385) wifi: wifi driver task: 3ffb2388, prio:23, stack:3584, core=0 I (385) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE I (395) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE I (415) wifi: wifi firmware version: c94f3e6 I (415) wifi: config NVS flash: enabled I (415) wifi: config nano formating: disabled I (415) wifi: Init dynamic tx buffer num: 32 I (415) wifi: Init data frame dynamic rx buffer num: 32 I (425) wifi: Init management frame dynamic rx buffer num: 32 I (425) wifi: Init management short buffer num: 32 I (435) wifi: Init static rx buffer size: 1600 I (435) wifi: Init static rx buffer num: 10 I (445) wifi: Init dynamic rx buffer num: 32 I (535) phy: phy_version: 4102, 2fa7a43, Jul 15 2019, 13:06:06, 0, 0 I (535) wifi: mode : sta (30:ae:a4:37:f3:d4) I (535) WIFI: SYSTEM_EVENT_STA_START I (1505) wifi: new:<8,2>, old:<1,0>, ap:<255,255>, sta:<8,2>, prof:1 I (2485) wifi: state: init -> auth (b0) I (2505) wifi: state: auth -> assoc (0) I (2515) wifi: state: assoc -> run (10) I (2645) wifi: connected with GZ123_EXT, channel 8, 40D, bssid = b0:be:76:cb:f6:4d I (2645) wifi: pm start, type: 1

I (2645) WIFI: SYSTEM_EVENT_STA_CONNECTED 4 401 [IP-task] vDHCPProcess: offer c0a80018ip

mahavirj commented 4 years ago

@bgintz-rsc Thanks for sending across log. Can you please help with one small request, please enable couple of debug statements from https://github.com/aws/amazon-freertos/blob/master/vendors/espressif/esp-idf/components/lwip/port/esp32/include/lwipopts.h#L823-L824 and help to share log?

Reason I am asking this is because, per your comment at https://github.com/espressif/esp-idf/issues/4060#issuecomment-532244623, when we enable lwip stack in AFR, application code is pretty much identical with whats there in IDF, hence bit surprised. Interim, I will try to replicate once I get access to TPLink TL-WA855RE at my end.

mahavirj commented 4 years ago

@bgintz-rsc

We could reproduce the issue but with FreeRTOS TCP stack only.

There are 2 solutions here:

Since this is not related to ESP-IDF anyhow, I will go ahead and close it from here.

Thank you.

bgintz-rsc commented 4 years ago

Just now checked back on this issue. (Was not notified by email for some reason). I cherry picked the #1696 commit and (also upgraded the extender code). Confirmed that this fixes the issue.

Thank you!!!