"Internet connection is offline" when connecting to AP without internet access - WiFi off/on fixes

Question

BACKGROUND We're trying to use an iOS app running on iPhone/iPad to give WiFi credentials to an embedded device (using an ARM SoC running Linux). The embedded device starts an AP (access point), we instruct the user to connect to this AP and then the user submits their WiFi credentials. After WiFi credentials are received the device drops the AP and connects to the WiFi the user gave credentials for. Initially, we try to hit a PHP page to get the list of WiFi networks the embedded device can see.

ISSUE We instruct the user to join XYZ network (in iOS they must background the app, go into settings and switch to our WiFi network). We listen for an app resumed from background notification, check the devices current ESSID (ensure its our AP ESSID) and try to hit a PHP page to receive the list of WiFi networks. Often, this connection fails reports "The internet connection appears to be offline" (or something of that nature).

We currently have a stop gap when this happens telling the user to toggle their WiFi off and then back on (in settings). The device will reconnect to our AP as it's the most recently connected network. This ALWAYS fixes the issue, we've never had to toggle the WiFi twice in order to reach the PHP page on the device. Please tell me any possible way we can avoid having to instruct the user to toggle WiFi and still access PHP pages on the embedded device.

Note: when we're connected to the AP (whether this bug is active or fixed) the device DOES NOT show the WiFi icon in the status bar. We assume this is because the AP doesn't have a viable connection to the internet (can only access pages served by the embedded device). We've been testing on a device that has LTE cellular access, but the error still says "Internet connection appears to be offline".

Obviously we have a DHCP server running on the embedded device.

Answer 1

It's looking like this was caused by an omission in our dhcpd.conf file. This omission was causing iOS to believe the connection was unviable.

We added the following line and are getting much better results:

option domain-name-servers 10.10.10.1;