Unable to receiveMessage: after NEHotspotConfiguration setup

Question

morejanus OP

Created 2w

Replies 7

Boosts 0

Participants 2

(iOS 17.3)

I'm using the Apple supplied iOS sample project "ConfiguringAWiFiAccessoryToJoinTheUsersNetwork" as a base to write an App to configure an existing WiFi device using the NEHotspotConfiguration API's. I have almost everything working, and can join the network and send a packet to the device to configure it. I know that it is working as the device responds properly to what I send it. But I am not able to receive the response back from the device to the packet sent. (Only need 1 packet sent and 1 packet received)

However. If I run a packet sniffer on the phone before running my test App, then I do get a response. No packet sniffer running, no response.

When I do a debugDescription on the NWConnection after it reaches ".ready", I notice that when the sniffer is running I'm using loopback lo0: [C1 connected 192.168.4.1:80 tcp, url: http://192.168.4.1:80, attribution: developer, path satisfied (Path is satisfied), viable, interface: lo0]

and I get a packet response in the NWConnection receiveMessage callback.

But with no sniffer running, I get interface en0: [C1 connected 192.168.4.1:80 tcp, url: http://192.168.4.1:80, attribution: developer, path satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, dns, uses wifi]

and there is no callback to the receiveMessage handler and the NWconnection eventually times out.

The interface used seems to be the only difference that I can see when I have a sniffer running. Any ideas as to why I can't see a response in "normal" operation?

Answered by morejanus in 842003022

Follow up for those interested :: I switched to using URLSession.dataTask() instead of NWConnection and now I receive the response and it's all working fine. So def a problem routing back at the NWConnection level.

Boost

Answer 1

DTS Engineer OP

Apple

2w

I’m gonna start by suggesting you read Extra-ordinary Networking, and specifically the Working with a Wi-Fi Accessory post that it links to. That explains a bunch of context that I’m gonna assume you understand.

Using the terminology from that post, is your accessory a bound accessory, a stand-alone accessory, or a gateway accessory?

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

1

Answer 2

morejanus OP

2w

It is a bound accessory. However, after it's configured and joined the local WiFi network, there will be no need for the phone to interact with it directly. It's a one and done.

0

Answer 3

DTS Engineer OP

Apple

2w

Right. So the plan is something like this:

Your accessory starts in AP mode, publishing a temporary network.
Your app calls NEHotspotConfigurationManager to force the device on to that network.
Your app opens a network connection to the accessory.
And uses that to send it configuration parameters.
Your accessory switches from AP mode to STA mode and joins the user’s Wi-Fi.
And we’re done.

Is that right?

And the problem you’re having is in step 3?

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

0

Answer 4

morejanus OP

2w

Yes, that's right. And it's all working EXCEPT I am unable to receive the response back from the device. So I send it a configuration packet (#4), and I know the device get's it because it does the "configuration" thing. Before #5, the device sends back an Acknowledgement packet saying it got the configuration packet, but my receiveMessage: callback is NOT called. The device is happy though and we go to #6.

BUT, if I have a 3rd party random iOS Sniffer App running at the time that I do this, MY App's receiveMessage: callback IS called. So I know that the device received my configuration packet in #4. . So the sniffer app is somehow affecting the functionality of my App.

So I'm wondering if there is something that I can do differently that will cause the same effect as the sniffer App. Since the configuration of the device IS working, I can just "assume" that the device received it, but I'd like to at least try to close the handshake loop.

0

Answer 5

morejanus OP

2w

Perhaps I should reach out to DTS then. I have the modified sample App I can provide, but of course can't provide the actual device. Was just hoping something would "twig" with someone based on the fact that a sniffer running causes different behavior.

(There's an uncertainty principle joke lurking here)

0

Answer 6

morejanus OP

1w

Recommended

Follow up for those interested :: I switched to using URLSession.dataTask() instead of NWConnection and now I receive the response and it's all working fine. So def a problem routing back at the NWConnection level.

0

Answer 7

DTS Engineer OP

Apple

1w

I switched to using URLSession… instead of NWConnection and now I receive the response and it's all working fine.

Hmmm, weird. URLSession uses the same infrastructure as NWConnection under the hood, so it’s rare to see an improvement like this when moving up the stack.

Still, if the server is speaking HTTP then URLSession is the right API for that, so I think you’re all set.

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

0