wifi.Radio: add method to get connected devices in access point mode

[ultranoise]

The core module wifi.Radio does not provide any method to know if there is any device connected to the board when it is configured as access point. I would like to suggest the development of the following method:

• .connected_clients -> list of of connected devices
• connected_clients[].IP -> IP address of a particular connected device

For applications when we have to transmit sensor data to connected devices (e.g. musical controllers), this is radically important. We usually do not receive any communication from the connected clients where they would expose their IP.

[anecdata]

What protocol is being used to communicate from the AP to the connected stations?

I think access to IP addresses of connected stations would involve capturing the IP_EVENT_AP_STAIPASSIGNED event and handling this structure:
https://docs.espressif.com/projects/esp-idf/en/release-v5.1/esp32s2/api-reference/network/esp_netif.html#_CPPv427ip_event_ap_staipassigned_t

edit: oh, this looks more direct (no change to event handlers required):
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/network/esp_netif.html#_CPPv434esp_netif_dhcps_get_clients_by_macP11esp_netif_tiP23esp_netif_pair_mac_ip_t
which requires knowing the MAC address:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/network/esp_wifi.html#_CPPv424esp_wifi_ap_get_sta_listP15wifi_sta_list_t

[ultranoise]

A typical use would be using OpenSoundControl (application level protocol), which is usually implemented with UDP. When I coded this in C or Arduino there were methods to obtain the clients' information. Ideally, it would be great to obtain it directly from wifi.Radio

[anecdata]

In the mean time, I don't know if you have control over which order the stations connect to the AP, but the AP will be 192.168.4.1 (espressif), and stations get assigned sequentially starting with 192.168.4.2. You can set a maximum number of stations allowed to connect in the start_ap() call (up to 10).

[ultranoise]

Thanks for the tip. In fact, this is what I have engineered at this moment. It really works well but it will definitely would be great to deal with this automatically :) I hope this could be developed!

[anecdata]

Can you describe the user case more? Are all connected stations equivalent, with the same packets going out to each, or is there some other way to know what each one can do?

I think the event handler process is more complex since stations connecting (and then obtaining an IP address) and later disconnecting means state for each station will have to be tracked in real time and persist until the next change.

The latter alternative above is a call to get a list of the IPs (and potentially MACs and AIDs) as needed - a snapshot of the current state of connected stations.

[ultranoise]

In my opinion it doesn't matter if different packets go to different clients when an enough informative Wifi event handler is available. In the past, I coded these applications in Arduino using similar code to this: https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/WiFiClientEvents/WiFiClientEvents.ino

The device transmiting would implement the following event handlers:

// WARNING: This function is called from a separate FreeRTOS task (thread)!
void WiFiEvent(WiFiEvent_t event)
{
    Serial.printf("[WiFi-event] event: %d\n", event);

    switch (event) {
        case ARDUINO_EVENT_WIFI_READY: 
            Serial.println("WiFi interface ready");
            break;
        case ARDUINO_EVENT_WIFI_SCAN_DONE:
            Serial.println("Completed scan for access points");
            break;
        case ARDUINO_EVENT_WIFI_STA_START:
            Serial.println("WiFi client started");
            break;
        case ARDUINO_EVENT_WIFI_STA_STOP:
            Serial.println("WiFi clients stopped");
            break;
        case ARDUINO_EVENT_WIFI_STA_CONNECTED:
            Serial.println("Connected to access point");
            break;
        case ARDUINO_EVENT_WIFI_STA_DISCONNECTED:
            Serial.println("Disconnected from WiFi access point");
            break;
        case ARDUINO_EVENT_WIFI_STA_AUTHMODE_CHANGE:
            Serial.println("Authentication mode of access point has changed");
            break;
        case ARDUINO_EVENT_WIFI_STA_GOT_IP:
            Serial.print("Obtained IP address: ");
            Serial.println(WiFi.localIP());
            break;
        case ARDUINO_EVENT_WIFI_STA_LOST_IP:
            Serial.println("Lost IP address and IP address is reset to 0");
            break;
        case ARDUINO_EVENT_WPS_ER_SUCCESS:
            Serial.println("WiFi Protected Setup (WPS): succeeded in enrollee mode");
            break;
        case ARDUINO_EVENT_WPS_ER_FAILED:
            Serial.println("WiFi Protected Setup (WPS): failed in enrollee mode");
            break;
        case ARDUINO_EVENT_WPS_ER_TIMEOUT:
            Serial.println("WiFi Protected Setup (WPS): timeout in enrollee mode");
            break;
        case ARDUINO_EVENT_WPS_ER_PIN:
            Serial.println("WiFi Protected Setup (WPS): pin code in enrollee mode");
            break;
        case ARDUINO_EVENT_WIFI_AP_START:
            Serial.println("WiFi access point started");
            break;
        case ARDUINO_EVENT_WIFI_AP_STOP:
            Serial.println("WiFi access point  stopped");
            break;
        case ARDUINO_EVENT_WIFI_AP_STACONNECTED:
            Serial.println("Client connected");
            break;
        case ARDUINO_EVENT_WIFI_AP_STADISCONNECTED:
            Serial.println("Client disconnected");
            break;
        case ARDUINO_EVENT_WIFI_AP_STAIPASSIGNED:
            Serial.println("Assigned IP address to client");
            break;
        case ARDUINO_EVENT_WIFI_AP_PROBEREQRECVED:
            Serial.println("Received probe request");
            break;
        case ARDUINO_EVENT_WIFI_AP_GOT_IP6:
            Serial.println("AP IPv6 is preferred");
            break;
        case ARDUINO_EVENT_WIFI_STA_GOT_IP6:
            Serial.println("STA IPv6 is preferred");
            break;
        case ARDUINO_EVENT_ETH_GOT_IP6:
            Serial.println("Ethernet IPv6 is preferred");
            break;
        case ARDUINO_EVENT_ETH_START:
            Serial.println("Ethernet started");
            break;
        case ARDUINO_EVENT_ETH_STOP:
            Serial.println("Ethernet stopped");
            break;
        case ARDUINO_EVENT_ETH_CONNECTED:
            Serial.println("Ethernet connected");
            break;
        case ARDUINO_EVENT_ETH_DISCONNECTED:
            Serial.println("Ethernet disconnected");
            break;
        case ARDUINO_EVENT_ETH_GOT_IP:
            Serial.println("Obtained IP address");
            break;
        default: break;
    }}

// WARNING: This function is called from a separate FreeRTOS task (thread)!
void WiFiGotIP(WiFiEvent_t event, WiFiEventInfo_t info)
{
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(IPAddress(info.got_ip.ip_info.ip.addr));
}

So an event is received for many different situations. Not only for the access point mode. The sender will deal with these events and decide what to do. In general, this option is great for having information of important things like:

• is the Access Point already up? (it usually takes some time)
• is it already connected to an external router? (it usually takes some time)
• has it disconnected from an external router?
• are there new clients connecting or disconnecting?
• etc

Therefore this Wifi event handler would be very useful not only for my particular application but for dealing with Wifi events in general. Should we change the name of this thread/issue to "wifi.Radio: add a Wifi event handler" ?

[anecdata]

I wouldn't change the title with the assumption of an implementation detail.

There is a similar event handler already in the core for espressif port, but in general we don't print from the core. There would still need to be an API to query the core from CircuitPython user code to get the (current) IP(s), since there is no way to interrupt python code from the core.

An event handler implementation is needed when the core has to handle the event in some way directly. But since CircuitPython user code still has to query the core to get the connected station IPs, I'm not sure there's an advantage to that implementation over the latter implementation approach in my earlier comment.

Bullet point 1 above for wifi access point is addressed with wifi.radio.ap_active (confirmed by the presence of an AP IP address).

Bullet points 2 and 3 above for wifi station are addressed with wifi.radio.connected (confirmed by the presence or absence of a station IP address).

A complication is that the API should be the same for espressif and raspberrypi. I don't know what is possible within the raspberrypi port to deliver IP addresses of connected stations, but that would need some research before implementing a feature (for either port, or both).

[romkey]

I've been reading the raspberrypi SDK and I'm not 100% confident about this but it looks like there's no exposed API for querying the DHCP server that's started in AP mode, only to start and stop the server. That said, this is C and it may be possible to extract this from the internal data structures that the DHCP server exposes, which would work but obviously be a horrible coding practice and likely to break without warning with an SDK update.

[romkey]

I posted a PR which implements a new property returning a list of associated stations, and another new property that returns the maximum number of stations that can be associated with the device. It works with Espressif CPUs and (with some limitations) the Pi Pico W.

[dhalbert]

Fixed by #8820.