[SOLVED] Severe Limitation to APSTA Mode

[chrismerck]

We are running into a rather severe limitation of APSTA mode. We expected to be able to keep the ESP in APSTA mode continuously, and rely on the AP-side for re-configuration. That does not seem to be viable.

To Reproduce:

Using esp-idf v3.1.

1. Configure ESP32 for APSTA mode, and set the sta config for an AP which does not exist.

2. NOTE: We observe STA_DISCONNECTED events every ~3 sec.

3. Now attempt to connect to ESP32's AP from another device. -- This fails 90% of the time.

---

Why this is important:

An ESP32-connected product may rely on the ESP's AP to allow a customer to change which WiFi network the ESP's STA is connected to. This must be robust to situations where the currently-configured network is no-longer available.

A workaround with a timeout is not acceptable, because the missing network may re-appear, and the ESP should reconnect as soon as the configured network becomes available again. A timeout would break that functionality.

---

Can anyone comment on why this is happening, or any suggestion?

[WiFive]

Do a manual scan on a single channel and only call connect when you see your AP.

[tommeyers]

Using the esp32/Arduino for a very similar task I found the components to be "fragile" and broke them a lot. I used the STA to connect for MQTT and AP for serving a web page for configuration. One thing that I found helpful was to capture all of the events and print them to serial. You may get more insight -- it helped me. The were and still are many events that seemed out-of-place.

I was prototyping a field configurator for my IoT projects. My conclusion is that AP with STA is too fragile and maybe too big of a memory footprint.

I think MZimmers has been working on a serial i/f for config.

I have implemeneted one in BT/ChromeApp and I am completing one for Serial (BT, USB,comx, audio/ir), mqtt, ip; for hosting on Android/linux/windows via nodejs, Browser.

The serial is small memory footprint and stable.

Tom Meyers

[jhinkle]

Just a few thoughts.

I've done a lot of work recently on the AP interface - here is what I found and it may help shed some light on your issue.

Check your event callback and see if you are issuing a esp_wifi_connect() in response to an event. If so, you may need to rethink exactly how you do that. LWIP may be giving more time constantly processing the STA connect that any AP connect request is being slowed down too much for the remote client.

I've instrumented and monitored all the AP network activity associated with making an access point connect using an ipad as the remote client.

My testing was done in my home with an access point located 3 feet from the ESP.

There was a LOT of message packets coming in -- I don't think the wifi mac has any sort of MAC filtering so it's up to the LWIP stack to do the filtering.

In order for a remote client to connect to your AP, the DHCP Server must negotiate an IP exchange with the client.

I found the ipad hit the DHCP Server multiple times even after the DHCP Server ACK'd an IP exchange.

As long as the client is requesting an IP from your AP, your client will not show it's connected.

With no STA activity, I've seen the ipad take up to 45 seconds to connect - I think this has to do more with the ipad connect process than with the ESP AP process. Other remote client may behave differently.

Once connected, the ipad issues a rash of DNS requests, ARP messages, and other messages. the ipad issues multiple connects to your port 80 (http).

If the LWIP stack is slow to respond to these AP requests (because you have it constantly doing a rapid connect (via an event)), the remote client (in my case an ipad) will either show it can not connect OR show a connect followed by a non connect shortly there after noting "No Internet Connection".

If your AP interface is being slowed due to STA connect constantly being processed - you may need to enforce a timer strategy for STA connect.

My comments are not a solution but maybe an insight as to what might be happening.

Joe

[Ritesh]

We are running into a rather severe limitation of APSTA mode. We expected to be able to keep the ESP in APSTA mode continuously, and rely on the AP-side for re-configuration. That does not seem to be viable.

To Reproduce:

Using esp-idf v3.1.

1. Configure ESP32 for APSTA mode, and set the sta config for an AP which does not exist.

2. NOTE: We observe STA_DISCONNECTED events every ~3 sec.

3. Now attempt to connect to ESP32's AP from another device. -- This fails 90% of the time.

---

Why this is important:

An ESP32-connected product may rely on the ESP's AP to allow a customer to change which WiFi network the ESP's STA is connected to. This must be robust to situations where the currently-configured network is no-longer available.

A workaround with a timeout is not acceptable, because the missing network may re-appear, and the ESP should reconnect as soon as the configured network becomes available again. A timeout would break that functionality.

---

Can anyone comment on why this is happening, or any suggestion?

We are also using AP+STA into different projects and facing issue while using ESP32 IDF 2.1 but when we switched to ESP32 IDF 3.1stable release into few products at that time not seen that type of issue yet.

But as you have noticed that if you use AP+STA then channel of AP will be of STA router with which ESP32 Device will be connected.so that when you won't get configured router or wrong SSID or wrong password or router OFF at that time AP channel will also getting changed as per STA connectivity process. So that may visualize effect like you are seeing sometimes.

Hope this may clear few things as per your concerns regarding AP+STA issues.

[chrismerck]

Thanks all for the replies on this. But Joe really nailed it:

Check your event callback and see if you are issuing a esp_wifi_connect() in response to an event. If so, you may need to rethink exactly how you do that. LWIP may be giving more time constantly processing the STA connect that any AP connect request is being slowed down too much for the remote client.

I added a 10 sec timer after receiving STA_DISCONNECTED, before esp_wifi_connect() is called again. --- The result is, clients are able to connect to the ESP32's AP, and remain connected. They do experience a glitch every ~13 sec as the ESP32 attempts to connect to the missing AP, but application protocol retries take care of that.

At least now the user can recover from a misconfiguration of the station!

[Ritesh]

Thanks all for the replies on this. But Joe really nailed it:

Check your event callback and see if you are issuing a esp_wifi_connect() in response to an event. If so, you may need to rethink exactly how you do that. LWIP may be giving more time constantly processing the STA connect that any AP connect request is being slowed down too much for the remote client.

I added a 10 sec timer after receiving STA_DISCONNECTED, before esp_wifi_connect() is called again. --- The result is, clients are able to connect to the ESP32's AP, and remain connected. They do experience a glitch every ~13 sec as the ESP32 attempts to connect to the missing AP, but application protocol retries take care of that.

At least now the user can recover from a misconfiguration of the station!

Yeah. That makes sense and we have also used 10 seconds of timer as reconnect timer into our application so that it won't get connect Everytime but will be after 10 seconds of delay.

[jcsbanks]

I am not sure how robust this is:

This is a task:

Code: Select all

void sta_reconnect_task(void * pvParameter){
	while(1){
		xEventGroupWaitBits(wifi_event_group, STA_DISCONNECTED_BIT, true, true, portMAX_DELAY);
		ESP_ERROR_CHECK(esp_wifi_connect());
	}	
}

This in the wifi event handler:

Code: Select all

    case SYSTEM_EVENT_STA_DISCONNECTED:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_DISCONNECTED");
	xEventGroupSetBits(wifi_event_group, STA_DISCONNECTED_BIT);

The difference is that the esp_wifi_connect() is in a different task, but there is no 10 second delay. Frequency of any glitches related would have to be considered against response time to reconnect.

Working in (very) initial testing. Thoughts?