Skip to content

SoftAP never populates station info after short power-off cycle #3638

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bryceschober opened this issue Sep 22, 2017 · 3 comments
Closed

SoftAP never populates station info after short power-off cycle #3638

bryceschober opened this issue Sep 22, 2017 · 3 comments

Comments

@bryceschober
Copy link
Contributor

bryceschober commented Sep 22, 2017

Basic Information

This is a copy of the issue espressif/ESP8266_NONOS_SDK#43, because my test case is an Arduino sketch, and I would take a workaround to force the station info to re-populate, if one existed.

https://github.com/esp8266/Arduino + https://github.com/plerup/makeEspArduino

Problem has been reproduced with https://github.com/esp8266/Arduino at master, 2.4.0-rc1, and update_sdk_2.1.0.

Description

The SoftAP never populates station info list after short power-off cycle. It will behave normally when booting after a long power-off time, or when a client manually disconnects and then reconnects.

But after only a short power-cycle, the client will automatically reconnect but not be included in the station info list. It will report the correct number of authenticated stations in wifi_softap_get_station_num(), but will not refresh their DHCP lease or add them to the list accessible via wifi_softap_get_station_info().

Sketch

#include <ESP8266WiFi.h>
// include plain C library
extern "C" {
#include "user_interface.h"
}

/* Define your own special thing that looks like a HardwareSerial and include it by building with
 * -DDEBUG_ESP_PORT=Debug, if you like. You don't want mine. ;-) */
#ifdef DEBUG_ESP_PORT
#include "Debug.h"
SerialDebugOut Debug;
#else
#define Debug Serial
#endif

#define YOUR_WIFI_SSID "esp8266_ap"
#define YOUR_WIFI_PASSWD ""

boolean waitingDHCP=false;
char last_mac[18];

// Manage incoming device connection on ESP access point
void onNewStation(WiFiEventSoftAPModeStationConnected sta_info) {
  Debug.printf("New Station :\n");
  sprintf(last_mac, MACSTR, MAC2STR(sta_info.mac));
  Debug.printf("MAC address : %s\n",last_mac);
  Debug.printf("Id : %d\n", sta_info.aid);
  waitingDHCP=true;
}

void setup() {

  static WiFiEventHandler e1;

  Debug.begin(921600);
  Debug.setDebugOutput(true);
  Debug.println();
  WiFi.mode(WIFI_AP);
  WiFi.softAP( YOUR_WIFI_SSID, YOUR_WIFI_PASSWD );

  // Event subscription
  e1 = WiFi.onSoftAPModeStationConnected(onNewStation);
}

boolean deviceIP(char* mac_device, String &cb, int& list_len);

void loop() {

  if (waitingDHCP) {
    String cb;
    int list_len = 0;
    if (deviceIP(last_mac, cb, list_len)) {
      Debug.printf( "Ip address: %s\n", cb.c_str() );
    } else {
      Debug.printf( "Problem during ip address request: %s", cb.c_str() );
    }
    Debug.printf( "Stations: %d list: %d\n", wifi_softap_get_station_num(), list_len );
  }

  delay(2000);
}

boolean deviceIP(char* mac_device, String &cb, int& list_len) {

  struct station_info *station_list = wifi_softap_get_station_info();
  list_len = 0;
  while (station_list != NULL) {
    ++list_len;
    char station_mac[18] = {0}; sprintf(station_mac, MACSTR, MAC2STR(station_list->bssid));
    String station_ip = IPAddress((&station_list->ip)->addr).toString();

    if (strcmp(mac_device,station_mac)==0) {
      waitingDHCP=false;
      cb = station_ip;
      return true;
    }

    station_list = station_list->next;
  }

  wifi_softap_free_station_info();
  cb = "DHCP not ready or bad MAC address";
  return false;
}

Debug Messages

<power on, and manually connect PC client a little later>
[AP] softap config unchanged
wifi evt: 7
wifi evt: 7
wifi evt: 7
wifi evt: 7
wifi evt: 7
wifi evt: 7
add 1
aid 1
station: 74:da:38:09:bc:0b join, AID = 1
wifi evt: 5
New Station :
MAC address : 74:da:38:09:bc:0b
Id : 1
Ip address: 192.168.4.2
Stations: 1 list: 1
wifi evt: 7
wifi evt: 7
wifi evt: 7
wifi evt: 7
wifi evt: 7
wifi evt: 7

<short (<10 second) power-off-on cycle here>

[AP] softap config unchanged
add 1
aid 1
station: 74:da:38:09:bc:0b join, AID = 1
wifi evt: 5
New Station :
MAC address : 74:da:38:09:bc:0b
Id : 1
Problem during ip address request: DHCP not ready or bad MAC address
Stations: 1 list: 0
Problem during ip address request: DHCP not ready or bad MAC address
Stations: 1 list: 0
Problem during ip address request: DHCP not ready or bad MAC address
Stations: 1 list: 0
Problem during ip address request: DHCP not ready or bad MAC address
Stations: 1 list: 0
wifi evt: 7
wifi evt: 7
wifi evt: 7
Problem during ip address request: DHCP not ready or bad MAC address
Stations: 1 list: 0

As you can see, the low-level debug output goes through the same sequence of events in both cases. In the short power-off case, the "wifi evt: 5" station connected event does trigger the user station connected handler, and count the client in the number of connected stations. The PC client actually connects, and reuses their previous DHCP lease, but the lease isn't refreshed (no dhcp client output in syslog), and the client list doesn't contain any items in the linked list.

@bryceschober
Copy link
Contributor Author

@me-no-dev @igrr : This looks like a bug in the low-level closed-source SDK. If a work-around existed (other than telling the user to power off for 60 seconds), I would take it. But I tried restarting the SoftAP by setting mode to none and then back to SoftAP, and that didn't help.

@igrr
Copy link
Member

igrr commented Sep 25, 2017

Looks like a valid bug which you could report through BBP, if you can reproduce it without Arduino. I doubt much can done in Arduino until this is fixed in the SDK, but let's keep this ticket open until then.

Edit: i see now that you have raised the issue in the nonOS SDK issue tracker, which might prevent BBP report from being accepted.

@devyte
Copy link
Collaborator

devyte commented Nov 8, 2019

WiFi.mode() would require a delay at the end (returns before being done, it's an asyn sequence). Without it, a call to softAP immediately afterwards could fail. This has been addressed with #6721 , with the restriction that the delay happens only when called from CONT context. When calling from SYS (e.g.: wifi event, Ticker), it's up to the user to serialize a waiting task (e.g.: Ticker).
Closing.

@devyte devyte closed this as completed Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants