How to open a TCP socket after NEHotspotConfigurationManager.shared.apply

Hello,


Im trying to open a TCP socket to transmit a data packet to the remote host device.

The iphone is already connected to the device after linking up via


NEHotspotConfigurationManager.shared.apply(myconfig)


I attempted to use a ping command I found on another forum.


func start(name: String, port: Int, tls: Bool, ping: String) {  
       self.ping = ping.data(using: .utf8)!  
       let streams = Stream.streamsToHost(name: name, port: port)  
       self.streams = streams  
       if tls {  
           let success = streams.inputStream.setProperty(StreamSocketSecurityLevel.negotiatedSSL as AnyObject, forKey: Stream.PropertyKey.socketSecurityLevelKey)  
           precondition(success)  
       }  
       for s in [streams.inputStream, streams.outputStream] {  
           s.schedule(in: .current, forMode: .defaultRunLoopMode)  
           s.delegate = self  
           s.open()  
       }  
   }  

   

func ping(streams: (inputStream: InputStream, outputStream: OutputStream)) { 
       let data = self.ping 
       let dataCount = data.count 
       let bytesWritten = data.withUnsafeBytes { (p: UnsafePointer) -> Int in 
           return streams.outputStream.write(p, maxLength: dataCount) 
       } 
       if bytesWritten < 0 { 
           NSLog("stream write error") 
       } else if bytesWritten < data.count { 
           NSLog("stream write short %d / %d", bytesWritten, data.count) 
       } else { 
           NSLog("stream task write %@", data as NSData) 
       } 
   }


however, the socket always seem to tmieout for me. See output below:


nw_socket_handle_socket_event [C1:1] Socket SO_ERROR [60: Operation timed out]


could anyone help shed some light on how I could resolve this please?


Thanks

Answered by DTS Engineer in 341640022

I ended up creating TCP socket using C thats called wihtin my swift class. Would this be allowed on Apple Store?

Only App Review can give you definitive answers about what will or won’t be allowed on the store. I will say that:

  • BSD Sockets is a supported API on our platforms.

  • BSD Sockets has many caveats on our platforms (you can find some, but not all, of them listed in this post), but many of them aren’t relevant if you’re talking to a locally-connected peer.

The purpose of this app is to:

1) Connect to my broadcasting device

2) Transmit my home router details to this device (SSID, security type and password)

3) This device will then attempt to connect to my home router using the credentials sent via my IOS app

The best way to implement this functionality is via WAC. Pasted in at the end of this email you’ll find my standard spiel about that.

Coming back to the issue you’re currently wrestling with, the most likely cause of the problem you’re seeing is the delay between the

NEHotspotConfigurationManager
completion handler being called and the Wi-Fi interface actually coming up completely. I generally avoid that problem by searching for the accessory using Bonjour [1]. Once the Wi-Fi interface comes up completely, Bonjour will discover the accessory and you can then communicate with it.

Does your accessory advertise itself with Bonjour? If not, I’d consider fixing this in your accessory. Bonjour is relatively easy to implement and it will make it easier to configure your accessory in all sorts of concern cases. Specifically, the combination of Bonjour and IPv6 guarantees that you’ll always be able to discover and talk to your accessory regardless of the local network environment.

If you can’t get your accessory to speak Bonjour then the first step here is discovering your accessory. How do you do that?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Bonjour is an Apple marketing term for:

The best way to integrate your Wi-Fi accessory with iOS is Wireless Accessory Configuration (WAC). You can learn more about this technology by following the links in QA1942 iOS Wi-Fi Management APIs.

The main drawback with WAC is that your accessory must be built under the aegis of the MFi programme, and my understanding is that supporting WAC requires modifications to your hardware.

IMPORTANT Much of the technical details about MFi accessories are not public, and thus can’t be discussed in this area of DevForums. If you want to get involved with MFi, you should follow the link to the MFi developer programme page in QA1942.

An alternative approach is to use

NEHotspotConfigurationManager
. This does not require any special privileges but it does have its own drawbacks. Specifically,
NEHotspotConfigurationManager
requires you to know in advance the SSID and password of the accessory’s access point. Unless all of your accessories have the same SSID and password, you’ll need to find a way to work these out.

There’s three common ways to do this:

  • Have the accessory advertise that information via Bluetooth LE, at which point you can find it using the Core Bluetooth API.

  • Print these details on the side of the accessory using some sort of barcode, and have your app scan that.

  • Ask the user )-:

My overall advice is that you pursue a dual strategy. In the long-term you should look at supporting WAC in future hardware, because that produces an ideal user experience. As for your current hardware, you should see what you can do with

NEHotspotConfigurationManager
.

If you’re writing new code for TCP it’s probably best to use Network framework rather than

Stream
. However, that’s unlikely to affect the problem you’re currently seeing. As to what’s causing that, it’s hard to say without more information.

Some questions:

  • Does the device you’re testing have a working WWAN?

  • Does the Wi-Fi it’s joining lead to the public Internet?

  • Is the target of your connection (that is,

    name
    in your code snippet) accessible via the public Internet? Or only via that specific Wi-Fi?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Eskimo,


first thanks for the response. the device im connecting to is broadcasting, but is not setup to the internet.

The purpose of this app is to:


1) Connect to my broadcasting device

2) Transmit my home router details to this device (SSID, security type and password)

3) This device will then attempt to connect to my home router using the credentials sent via my IOS app


May I ask another question? Im quite new to Swift, however I am happy in C/C++. I ended up creating TCP socket using C thats called wihtin my swift class.

Would this be allowed on Apple Store?

Accepted Answer

I ended up creating TCP socket using C thats called wihtin my swift class. Would this be allowed on Apple Store?

Only App Review can give you definitive answers about what will or won’t be allowed on the store. I will say that:

  • BSD Sockets is a supported API on our platforms.

  • BSD Sockets has many caveats on our platforms (you can find some, but not all, of them listed in this post), but many of them aren’t relevant if you’re talking to a locally-connected peer.

The purpose of this app is to:

1) Connect to my broadcasting device

2) Transmit my home router details to this device (SSID, security type and password)

3) This device will then attempt to connect to my home router using the credentials sent via my IOS app

The best way to implement this functionality is via WAC. Pasted in at the end of this email you’ll find my standard spiel about that.

Coming back to the issue you’re currently wrestling with, the most likely cause of the problem you’re seeing is the delay between the

NEHotspotConfigurationManager
completion handler being called and the Wi-Fi interface actually coming up completely. I generally avoid that problem by searching for the accessory using Bonjour [1]. Once the Wi-Fi interface comes up completely, Bonjour will discover the accessory and you can then communicate with it.

Does your accessory advertise itself with Bonjour? If not, I’d consider fixing this in your accessory. Bonjour is relatively easy to implement and it will make it easier to configure your accessory in all sorts of concern cases. Specifically, the combination of Bonjour and IPv6 guarantees that you’ll always be able to discover and talk to your accessory regardless of the local network environment.

If you can’t get your accessory to speak Bonjour then the first step here is discovering your accessory. How do you do that?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Bonjour is an Apple marketing term for:

The best way to integrate your Wi-Fi accessory with iOS is Wireless Accessory Configuration (WAC). You can learn more about this technology by following the links in QA1942 iOS Wi-Fi Management APIs.

The main drawback with WAC is that your accessory must be built under the aegis of the MFi programme, and my understanding is that supporting WAC requires modifications to your hardware.

IMPORTANT Much of the technical details about MFi accessories are not public, and thus can’t be discussed in this area of DevForums. If you want to get involved with MFi, you should follow the link to the MFi developer programme page in QA1942.

An alternative approach is to use

NEHotspotConfigurationManager
. This does not require any special privileges but it does have its own drawbacks. Specifically,
NEHotspotConfigurationManager
requires you to know in advance the SSID and password of the accessory’s access point. Unless all of your accessories have the same SSID and password, you’ll need to find a way to work these out.

There’s three common ways to do this:

  • Have the accessory advertise that information via Bluetooth LE, at which point you can find it using the Core Bluetooth API.

  • Print these details on the side of the accessory using some sort of barcode, and have your app scan that.

  • Ask the user )-:

My overall advice is that you pursue a dual strategy. In the long-term you should look at supporting WAC in future hardware, because that produces an ideal user experience. As for your current hardware, you should see what you can do with

NEHotspotConfigurationManager
.
How to open a TCP socket after NEHotspotConfigurationManager.shared.apply
 
 
Q