iOS 18; Can no longer connect app to camera over Ad Hoc insecure network

Camera is configured to Ad Hoc Wi-Fi network (insecure TCP).

I try to avoid the term ad hoc when it comes to Wi-Fi, because different folks use it to mean different things. I talk about this more in Wi-Fi Fundamentals.

Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't

It’s hard to say without more information.

Do we configure ATS correctly for this scenario?

No. You should only need NSAllowsLocalNetworking.

I’ll note that, if ATS were blocking this request, it would fail promptly and with a helpful log message. Given the symptoms you’ve described, I very much doubt this is an ATS issue.

What should I look for in the Console log when CFNetwork profile is installed?

That’s not where I’d go to first. More on this below.

Should I file a TSI?

No. Well, TSIs technically don’t exist any more [1]. Instead, DTS spends a lot more time on the forums these days, so everyone can benefit from our work.

Reading your post it wasn’t clear what the actual failure mode is. You wrote:

App simply doesn't get any responses!

What does that mean exactly? URLSession requests have a default timeout so, if you get no response from the server, you should expect to time out within a minute or two [2]. Is that what happens in your case?

Beyond that, what I’d do next is to look at what’s happening on the ‘wire’. It’s quite possible that the device is sending a request but your accessory is not responding. Use an RVI packet trace for this.

That’ll also let you compare the iOS 17 and 18 behaviour.

ps I have a bunch of info about working with accessories in my Extra-ordinary Networking > Working with a Wi-Fi Accessory post. None of it directly relevant to your current issue, but I recommend that you keep it in mind.

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

[1] Rather, we have DTS code-level support request.

[2] The exact timeout depends on exactly what’s failing on the wire.

Thanks a lot Quinn/ @DTS Engineer—as always you to invaluable help to us! 😀

And sorry not for responding until now... I got busy with something else and then went on holiday 😅

By using the rvictl tool as you suggested we were able to see a difference between iOS 17/18!

In iOS 18 the SYN message has also the ECE and CWR flags set! Our device responds with RST and then iOS 18 tries two more times with same result:

Isn't iOS 18 supposed to fallback on RST and send new SYN without those flags set?

If not then what are the alternatives?

• Can we configure this for our app? We use NSMutableURLRequest.
• Do we need to update some really old firmware in our device? This is most likely not possible and will make some customers sad :(

Thanks again for the info about the rvictl tool!

Isn't iOS 18 supposed to fallback on RST and send new SYN without those flags set?

I don’t know enough about that part of TCP to offer an opinion on this. Fortunately, my opinion doesn’t actually matter (-: If you think this should change, you should file a bug and our TCP experts will take a look.

Please post your bug number, just for the record.

If not then what are the alternatives?

Fix your accessory, obviously (-:

You won’t be able to workaround this at the URLSession level. It simply doesn’t give you control over low-level details like this.

You might be able to work around this by dropping down to Network framework. It has a disableECN option that you can set.

Of course, the drawback here is that you have to implement HTTP on top of Network framework. If your HTTP requirements are really simple, you could tackle that directly. If not, see the advice in the HTTP alternatives section of TN3151 Choosing the right networking API.

I recommend that you prototype this before going too far. That is, use NWConnection to open a TCP connection your accessory with disableECN set. If that avoids the RST, you can then decide how you want to handle HTTP.

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

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

I have now created a feedback with id: FB17345333.

Ta!

Wondering if we should file a TSI too?

Such a TSI code-level support request would be routed to me, and I’m gonna give you the same answer there as I’m giving you here.

Did you try my Network framework / disableECN suggestion?

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

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

@DTS Engineer /Quinn, thanks for the tips page... But please forgive me when you only get in here occasionally then you can easily forget those... but I will try not to use the 'reply' in the future... but maybe 'reply' should just be removed then... :)

Such a TSI code-level support request would be routed to me, and I’m gonna give you the same answer there as I’m giving you here.

Oh wauw! :D

Did you try my Network framework / disableECN suggestion?

No I did not try that because it will not solve our problem as such...

The thing is that we believe iOS 18 should do a fallback! Creating the TSI was to get Apple's network engineers to give their take on that, i.e., conclude that Apple network has a bug or not.

Doesn't that make sense instead of doing stop-gap solutions?

And yes, I feel like Feedback has never brought us anywhere sorry... it seems to us no-one is actually looking at them 😅

Thanks a million as usual :)

Doesn't that make sense instead of doing stop-gap solutions?

That depends on how long you’re prepared to wait |-:

Your position also assumes that you’ve correctly identified the problem. If you have, then you can add that to your bug report which will help it gain traction. OTOH, if disableECN doesn’t help, it’d warrant further investigation on your side.

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

@DTS Engineer , I don't assume that we have correctly identified the problem,

But to us it seems like a failed negotiation for TCP SYN, i.e., Apple network framework not doing fallback to a basic TCP SYN.

Then it was our idea/hope to get a domain expert from Apple to give their five cents on it.

But it sounds like that is not possible before I try that disableECN and so I will try to look into that one day... 🥹

Cheers!