Wi-Fi Raw Socket Disconnection Issue on iPhone 17 Series

Question

Created 1w

Replies 4

Boosts 1

Participants 3

On my iPhone 16 Pro and iPhone 16 Pro Max devices, running iOS 26.0, 26.0.1, and 26.1, Wi-Fi raw socket communication works flawlessly. Even after keeping the connection active for over 40 minutes, there are no disconnections during data transmission.

However, on the iPhone 17 and iPhone 17 Pro, the raw socket connection drops within 20 seconds. Once it disconnects, the socket cannot reconnect unless the Wi-Fi module itself is reset.

I believe this issue is caused by a bug in the iPhone 17 series’ communication module. I have looked into many cases, and it appears to be related to a bug in the N1 chipset.

Are there any possible solutions or workarounds for this issue?

Answered by DTS Engineer in 864437022

Thanks for the clarifications.

Just FYI, in networking, raw socket usually refers to raw IP sockets, hence my confusion.

So, lemme summarise the issue:

You have an iOS app.
It talks to a Wi-Fi based accessory over TCP.
With iPhone 16, this all works as expected.
With iPhone 17, things go wrong, such that your TCP socket disconnects after 20 seconds.
After that, your app is unable to reconnect.
And the only way to resolve the issue is to restart the Wi-Fi subsystem on your accessory.

Is that right?

If so, this sounds eminently bugworthy. While there are lots of ways that local networking can go wrong, the fact that this fails when the only variable you change is moving from iPhone 16 to 17 suggests that it’s caused by a Wi-Fi level issue on iPhone 17.

DevForums focuses on Apple APIs and tools, and isn’t really set up to help with Wi-Fi level issues. Given your description of the problem, I think it makes sense for you to file a bug so that our Wi-Fi engineering team can investigate.

In your bug, make it clear as to whether you’re the accessory developer or you’re using an accessory built by someone else.

When you file your bug, make sure to install the Wi-Fi for iOS/iPadOS debug profile so that your sysdiagnose log captures extra debugging information. I also think it’d be helpful for you to include a packet trace. You should definitely include an [RVI packet trace][packet], but if you have the ability to take a packet trace from the perspective of your accessory then include that as well.

Once you’re done, please post your bug number, just for the record.

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

Boost

Answer 1

DTS Engineer OP

Apple

1w

Wi-Fi raw socket

Please clarify what you mean by “Wi-Fi raw socket”. What API are you actually calling?

Wi-Fi module itself is reset.

And what do you mean by this? Does it involve doing something on the iOS device? Or is this “Wi-Fi module” part of something you’ve created, like a Wi-Fi based accessory?

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

0

Answer 2

iwp OP

6d

Thank you for your response.

By “Wi-Fi raw socket,” I was referring to a TCP socket connection implemented in Flutter (using the dart:io Socket API). The app communicates directly with an external Wi-Fi device — specifically, a car dashcam (black box) — by connecting to its local Wi-Fi network (no Internet involved) and exchanging binary data over a socket.

Regarding the “Wi-Fi module reset,” this refers to restarting the dashcam’s internal Wi-Fi module, not anything done on the iOS device. Once the socket connection drops on the iPhone 17 series, the app cannot reconnect to the dashcam unless the dashcam’s Wi-Fi is turned off and back on again.

0

Answer 3

DTS Engineer OP

Apple

6d

Recommended

Thanks for the clarifications.

Just FYI, in networking, raw socket usually refers to raw IP sockets, hence my confusion.

So, lemme summarise the issue:

You have an iOS app.
It talks to a Wi-Fi based accessory over TCP.
With iPhone 16, this all works as expected.
With iPhone 17, things go wrong, such that your TCP socket disconnects after 20 seconds.
After that, your app is unable to reconnect.
And the only way to resolve the issue is to restart the Wi-Fi subsystem on your accessory.

Is that right?

If so, this sounds eminently bugworthy. While there are lots of ways that local networking can go wrong, the fact that this fails when the only variable you change is moving from iPhone 16 to 17 suggests that it’s caused by a Wi-Fi level issue on iPhone 17.

DevForums focuses on Apple APIs and tools, and isn’t really set up to help with Wi-Fi level issues. Given your description of the problem, I think it makes sense for you to file a bug so that our Wi-Fi engineering team can investigate.

In your bug, make it clear as to whether you’re the accessory developer or you’re using an accessory built by someone else.

When you file your bug, make sure to install the Wi-Fi for iOS/iPadOS debug profile so that your sysdiagnose log captures extra debugging information. I also think it’d be helpful for you to include a packet trace. You should definitely include an [RVI packet trace][packet], but if you have the ability to take a packet trace from the perspective of your accessory then include that as well.

Once you’re done, please post your bug number, just for the record.

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

0

Answer 4

Jie-Hu OP

1d

We have also encountered a similar issue. Our product establishes a socket connection with an iPhone after connecting via Wi-Fi. However, recently, a large number of users with iPhone 17 series devices have reported that their iPhone 17 series products cannot communicate normally with our product. The specific symptom is that the socket connection fails due to timeout.

0