Unable to receiveMessage: after NEHotspotConfiguration setup

Question

morejanus OP

Created 1w

Replies 6

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?

Boost

Answer 1

DTS Engineer OP

Apple

1w

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

1w

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

1w

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

6d

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

4d

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

2d

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