Post not yet marked as solved
Two more colleagues are now suffering from this issue. Any updates?
Post not yet marked as solved
Several people on the internet suggest removing (relevant, com.apple.pkg.CLTools_*?) receipts from /Library/Apple/System/Library/Receipts, but that requires (temporarily) disabling SIP.
Might be a solution for some, but I'd rather have a cleaner one...
Post not yet marked as solved
Today I even had to re-install the certificate 3 times! (instead of once every day...)
Any fix for this?
(I already have all Apple certificates installed)
Post not yet marked as solved
I also got hit by this issue, even after re-installing Apple's root certificates.
My workaround is to delete my development certificate from the keychain, download it from the developer web site, and re-install it.
The developer certificate will then be trusted for the remainder of the day.
However, the next morning it is not trusted again!
So I have to apply this workaround every morning... Huh?
What's the proper fix?
Post not yet marked as solved
Apparently somebody else posted the same issue on Stack Overflow about two months ago:
https://stackoverflow.com/questions/63130232/cncopycurrentnetworkinfo-not-working-with-ios-14
I suppose this is intended behaviour to better protect the user's privacy, but how can we achieve our goal?
(We have no intention of invading privacy, we just want to prevent unnecessary costs for our users)
Post not yet marked as solved
Unfortunately this issue is still present in iOS 14 GM (18A373) with Xcode 12 GM (12A7208).
Post not yet marked as solved
Still present in iOS 14 Beta 8 (with Xcode 12 Beta 6 - there's again no Xcode update?):
all HTTP/1.1 200 OK replies are ignored
NOTIFY * HTTP/1.1 notifications are delivered
Post not yet marked as solved
Still present in iOS 14 Beta 7 (with Xcode 12 Beta 6 - there's no Xcode update, yet?).
Not sure whether this is true for previous beta's, but it currently seems to be like this: all HTTP/1.1 200 OK replies are ignored
the NOTIFY * HTTP/1.1 notifications are delivered to NWConnectionGroup's receive handler
Post not yet marked as solved
Unfortunately this issue is also present in iOS 14 Beta 6.
Post not yet marked as solved
Matt, we had the crash with iOS 14 Beta 4 and Xcode 12 Beta 4, but can't reproduce it with iOS 14 Beta 5 and Xcode 12 Beta 5 (released a few hours ago) so far.
However, SSDP is still failing for us due to an address already being in use, as discussed in this thread - https://developer.apple.com/forums/thread/652125?answerId=627943022#627943022.
Would be great if you could give us some assistance there!
Post not yet marked as solved
We had the crash with iOS 14 Beta 4 and Xcode 12 Beta 4, but can't reproduce it with iOS 14 Beta 5 and Xcode 12 Beta 5 (released a few hours ago) so far.
However, SSDP is still failing for us due to the address already being in use ([48: Address already in use]) with Beta 5.
Post not yet marked as solved
This is what we see in Xcode (where 192.168.1.165 is the IP address of the device that we are trying to discover via SSDP):
2020-08-18 16:36:44.804834+0200 DemoApp[632:112993] [] nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW <some-UUID> [48: Address already in use]
2020-08-18 16:36:44.806020+0200 DemoApp[632:112993] [connection] nw_endpoint_flow_setup_channel [C8 192.168.1.165:1900 initial channel-flow (satisfied (Path is satisfied), interface: en0, scoped, ipv4, dns)] failed to request add nexus flow
2020-08-18 16:36:44.808119+0200 DemoApp[632:112993] [connection] nw_endpoint_handler_create_from_protocol_listener [C8 192.168.1.165:1900 failed channel-flow (satisfied (Path is satisfied), interface: en0, scoped, ipv4, dns)] nw_endpoint_flow_pre_attach_protocols
2020-08-18 16:36:44.808930+0200 DemoApp[632:112993] [connection] nw_connection_create_from_protocol_listener_on_nw_queue [C8] Failed to create connection from listener
2020-08-18 16:36:44.809410+0200 DemoApp[632:112993] [] nw_ip_channel_inbox_handle_new_flow nw_connection_create_from_protocol_listener_on_nw_queue failed
And this is the crash (Thread 10: EXC_BAD_ACCESS (code=1, address=0x10)) stack trace that we see after a while:
libnetwork.dylib`__57-[NWConcrete_nw_listener handleInbound:addProtocolInbox:]_block_invoke:
0x19e1530c8 <+0>: ldp x8, x1, [x0, #0x20]
0x19e1530cc <+4>: mov x2, x8> 0x19e1530d0 <+8>: ldr x3, [x2, #0x10]!
0x19e1530d4 <+12>: mov x0, x8
0x19e1530d8 <+16>: braa x3, x2
Is this an iOS 14 Beta 4 issue? Or are we doing something wrong?
Post not yet marked as solved
Update: we did eventually get the entitlement, but using the NWMulticastGroup our test App still crashes as before.
Post not yet marked as solved
Note: above results are for our existing custom SSDP implementation which uses CocoaAsyncSocket.
We're also trying to migrate to NWMulticastGroup for iOS 14+ (short term solution; migrate to Bonjour later), but our test App crashes (EXC_BAD_ACCESS (code=1, address=0x10)):
libnetwork.dylib`__57-[NWConcrete_nw_listener handleInbound:addProtocolInbox:]_block_invoke:
0x1b02130c8 <+0>: ldp x8, x1, [x0, #0x20]
0x1b02130cc <+4>: mov x2, x8> 0x1b02130d0 <+8>: ldr x3, [x2, #0x10]!
0x1b02130d4 <+12>: mov x0, x8
0x1b02130d8 <+16>: braa x3, x2
Is this because we still don't have received the entitlement?
What do we need to do to get this entitlement?
(Other developers in our company that create App Store Apps using our communication library requested the entitlement at the same time and they all received it for those App Store Apps, but we still did not receive ours for in-house testing).
Post not yet marked as solved
Same with Xcode 12.0 beta 4 (12A8179i).
