Looking for a way to track if the portal is up or not

[softwaregravy]

I'm looking for a way to determine if the portal is available or not from code. We'd like to display an icon/change visible behavior if the portal is available.

I've hooked in to the onDetect callback for starting the portal, and then we have the onConnect. With a successful connection, my code works as I put a portal_available = true in the first callback, and a portal_available = false in the second. However, a _stopPortal() call happens for a few other reasons like timeout/disconnect or reset. I'm not seeing any way to get a hook to know we shut down.

One avenue I've looked into is the WifiClient on the WebServer, but this only works if someone has actually connected. I'm looking for if the portal is available at all.

// assume we have this
static WebServer   server;
static AutoConnect auto_connect(server);

// and we are trying to find whether the portal is up
WifiClient wifi_client = server.client();
// I assume this is true only if someone has connected to the portal. Maybe I'm wrong?
wifi_client.connected(); 

Webserver.client()
WifiClient.connected()

I also looked into WebServer which has a WifiServer underneath it which does have an operator bool() which I think would give me what I'm looking for. But I don't see a good way to get to that object from AutoConnect or WebServer. WebServer doesn't seem to expose this instance at all.

Thoughts?

An alternative would be to ask for another callback on AutoConnect probably from inside _stopPortal(), or for AutoConnect itself to keep track of the status and provide a bool method to check.

Thoughts on this?

Thanks

[Hieromon]

@softwaregravy Your question may lead to an AutoConnect enhancement. I would like to move this topic to Discussions and discuss specific implementations there.
Thank you.

[softwaregravy]

I think the easiest implementation might be for AutoConnect to keep track of the state itself. With a simple boolean. The question is where to set this.

I might suggest setting to true in _softAP and then to false in _stopPortal and handleRequest

• for _softAP. I think this covers both the begin and handleRequst use cases, which I think are the only 2 places the portal starts
• the _stopPortal case covers stopping after unsuccessful connections, and then also in handleRequest covers successful connections on line 592

Then we just expose this via a simple boolean check isPortalAvailable or something.

[softwaregravy]

For illustrative/discussion purposes: #545

I found that the cleanest place to integrate the checks was in the DNS control. I'm testing this out in my project.

[Hieromon]

@softwaregravy Thanks for your preliminary survey and PR.
Before designing a new API, I have traced your mention below. This is to get an accurate picture of your situation and what you want. If my understanding differs from your goals, please point it out.

a _stopPortal() call happens for a few other reasons like timeout/disconnect or reset. I'm not seeing any way to get a hook to know we shut down.

Yes, you are correct. Captive Portal - i.e., just a spoofed response to a DNS lookup for Internet connection verification that occurs on a new connection attempt from the client device; it needs a DNS server and SoftAP to work, so if we can detect that one or the other is missing, I think we can fulfill your request. So, about your approach as follows:

I think the easiest implementation might be for AutoConnect to keep track of the state itself. With a simple boolean.
I might suggest setting to true in _softAP and then to false in _stopPortal and handleRequest

I believe your PR #545 meets the above requirements but would suggest adding further detection conditions. It is an approach that allows the isPortalAvailable function to determine state at a point in time, rather than a DNS and SoftAP state trace on AutoConnect itself.

In AutoConnectCore<T>::isPortalAvailable without _portalAvailable flag:

• Retrieval a logical value of WiFi.getMode() & WIFI_MODE_AP
• WiFi.softAPIP() is identical to _apConfig.apip
• _dnsServer is not nullptr

isPortalAvailable() is true when the above conditions are met. This is semantically equivalent to your approach. And it can keep track of the captive portal availability even when SoftAP is intentionally deactivated outside of AutoConnect.
The pseudo-code for isPortalAvailable would probably is following:

bool isPortalAvailable(void) {
  bool state = WiFi.getMode() & WIFI_MODE_AP;
  state &= (WiFi.softAPIP() == _apConfig.apip);
  state &= (_dnsServer.get() != nullptr);
  return state;
}

How about this?

[softwaregravy]

I think getting to a solution without adding another variable is a much better approach. 👍

I'm probably not as familiar with the call to softAPIP(). I'm sure you're much more familiar. For my reading, it seems to be a thin wrapper around esp_netif_get_ip_info which seems like it may not be indicative of current state:

IPAddress WiFiAPClass::softAPIP()
{
    if(WiFiGenericClass::getMode() == WIFI_MODE_NULL){
        return IPAddress();
    }
	esp_netif_ip_info_t ip;
    if(esp_netif_get_ip_info(get_esp_interface_netif(ESP_IF_WIFI_AP), &ip) != ESP_OK){
    	log_e("Netif Get IP Failed!");
    	return IPAddress();
    }
    return IPAddress(ip.ip.addr);
}

Docs for esp_netif_get_ip_info

If the interface is up, IP information is read directly from the TCP/IP stack. If the interface is down, IP information is read from a copy kept in the ESP-NETIF instance

If the portal is brought up, shut down, and then brought up again, is there any value in the check to the _apConfig.apip?

[Hieromon]

@softwaregravy

it seems to be a thin wrapper around esp_netif_get_ip_info which seems like it may not be indicative of current state:
If the portal is brought up, shut down, and then brought up again, is there any value in the check to the _apConfig.apip?

I understand your concern. The esp_netifs static structure is only initialized when tcpInit() is run from the wifiLowLevelInit(). Usually, this is a WiFi module activation within ESP32 and is also performed by WIFI_MODE_STA only. However, set_esp_interface_ip() overwrites it with the new IP given in the argument, so WiFi.softAPIP() and _apConfig.apip will be in sync if WiFiAPClass::softAPConfig() is executed reliably in AutoConnectCore<T>::_softAP().

On other hand, stopping SoftAP using WiFi.mode(~WIFI_MODE_AP) only will probably cause softAPIP() still return the equivalent _apConfig.apip. In that case, if the SoftAP is started outside of AutoConnect and is configured with the same IP as the ESP32AP, it will seem like the portal is open. But the DNSServer remains shut down, so Internet transparency validation requests from client devices pass through. This use case assumes the coexistence of ESP-NOW and AutoConnect. Related to #210.

So, I think it is probably okay.

[softwaregravy]

Seems solid. 👍

[Hieromon]

@softwaregravy
For now, I have implemented the bool AutoConnectCore<T>::isPortalAvailable(). You can evaluate it in the patches/543 branch. Please give it a try. Let me know if there are some problems in your use case.
I plan to release AutoConnect v1.4.1 soon, could you wait until v.1.4.1 release for this enhancement?

Oh, yes. A little bonus: If you build by giving the AC_USE_PORTALIDENTIFER AC_SHOW_PORTALIDENTIFER macro in AutoConnectDefs.h, you will see the following checkmark in the captive portal state. In PlatformIO, it is enabled by specifying build_flags=-DAC_USE_PORTALIDENTIFIER build_flags=-DAC_SHOW_PORTALIDENTIFIER.

[softwaregravy]

The boolean check appears to be working well. 👍

The check-mark has limited utility for me. We don't connect to the weberver unless the portal is active, so it's just always checked.

Thank you!

PS. I tested on a local implementation by copying your suggestion. Didn't actually test your patch branch.

[Hieromon]

@softwaregravy, Glad it worked out for your use case. Indeed, the checkmark is just an indicator, so its usefulness will be limited.
I will release it as AutoConnect v1.4.1 after validation with my test cases.

Thank you for your contribution.

[Hieromon]

This feature was released in AutoConnect v1.4.1.