How to prevent to open captive portal while connecting to Wifi?

Question

ExcellentWebWorld OP

Created Jan ’23

Replies 6

Boosts 0

Views 1.2k

Participants 2

Hi everyone,

Why captive portal window open When I connect to the IoT device, from my app (NEHotspotConfiguration).

Steps to reproduce: Call NEHotspotConfigurationManager.shared.apply. SSID, Passphrase, isWEP=false, joinOnce=true. Connection response without error.

This is my code

let hotspotConfig = NEHotspotConfiguration(ssid:withSSID, passphrase:passPhrase, isWEP: false)
hotspotConfig.joinOnce = true
NEHotspotConfigurationManager.shared.apply(hotspotConfig) {[weak self] (error) in
      if(withSSID.lowercased() == “wifi ssid)
      {
        if let error = error{
          if error.localizedDescription == "already associated."
          {
            print("NotConnected")
            
          }
          else{
           print(error.localizedDescription)          }
        }
        else {
          print("Connected")
        }
      }
       
    }

any help we would be appreciated.

Boost

Answer 1

ExcellentWebWorld OP

Feb ’23

Please provide any solution for this Captive Portal Thanks

0

Answer 2

DTS Engineer OP

Apple

Feb ’23

Why captive portal window open When I connect to the IoT device

Because the system’s captive network probes have run and your accessory has responded in a way that makes it look like the network is captive. The most likely cause is that your accessory has implemented an HTTP server with some sort of ‘catch all’ functionality. So, when the system runs a probe [1], rather than just failing as it should the accessory is returning a valid HTTP response. However, this isn’t the expected response and the system interprets that to mean that this network is captive.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] While the details of these probes are not considered API, one part of the current implementation is getting the http://captive.apple.com resource.

0

Answer 3

ExcellentWebWorld OP

Feb ’23

Okay understood, Yes we have implemented an HTTP server on our accessory but actually my use cases are

Case 1 When I connect my accessory throw the application developed by us at that time captive window should not open.

Case 2 When I connect my accessory throw Wifi setting menu at the time this captive window should be open.

But problem is that the captive window opens both cases. So I just want to know how can prevent the captive window to open in case 1. or are there any provisions to modify the captive request header?

0

Answer 4

DTS Engineer OP

Apple

Mar ’23

Our captive network infrastructure is not meant to be used for accessory integration, so you’re going to run into problems here. Let’s start with a fundamental question:

Is this accessory something that the user adds to their own network? So it only acts as an AP [1] during the setup phase? For example, a Wi-Fi printer.
Or is this accessory a standalone thing, where you don’t expect the user to add it to their network? For example, a Wi-Fi camera that folks use in the field.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I’m using terms from my Wi-Fi Fundamentals post.

0

Answer 5

ExcellentWebWorld OP

Mar ’23

our accessory use AP [1] for configuration setup but when we get connected state then captive window is open

0

Answer 6

DTS Engineer OP

Apple

Mar ’23

I not sure I understand that. Is the ultimate goal to get your accessory on to the user’s Wi-Fi network?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0