I have an issue in my app where if a client is running my app but does not have wifi enabled, the app does not find my service and returns an "Unknown error" CFNetServiceError code 72000. The client enables wifi, connects, and my app is clueless.
The obvious fix is to add a notification for when a local wifi network is connected and reinitiate the NSNetServiceBrowser's search.
I don't know how to do that in C, so I was hoping to use Reachability. To my dismay, the solution I seek has recently been removed.
This is from the Reachability ReadMe file.
Removal of reachabilityForLocalWiFi
Older versions of this sample included the method reachabilityForLocalWiFi. As originally designed, this method allowed
apps using Bonjour to check the status of "local only" Wi-Fi (Wi-Fi
without a connection to the larger internet) to determine whether or
not they should advertise or browse. However, the additional
peer-to-peer APIs that have since been added to iOS and OS X have
rendered it largely obsolete. Because of the narrow use case for this
API and the large potential for misuse, reachabilityForLocalWiFi has
been removed from Reachability.
Ok, fine. But what the hell are these additional APIs? I need a method. :(
Related
What actual method calls, excluding Bonjour, triggers the "would like to find and connect to devices on your local network" permission notification on iOS 14?
This is the screen shot from the WWDC session on this new permission. Which is only somewhat helpful as an overview. I'm more interested in figuring out what all method calls trigger this.
If you're using react native with a debug configuration, then you are including all the code responsible for communicating with your dev machine so you can probably ignore this message.
However it's best to check you have no other libs that require access too. To do this just build a Release version and see if the message persists.
In a nutshell, Bonjour. Its use is no longer "transparent". See https://developer.apple.com/videos/play/wwdc2020/10110/ for more information:
If your app interacts with devices using Bonjour or other local networking protocols, you must add support for local network privacy permissions in iOS 14.
Even an existing app is subject to this rule; the first attempt to use Bonjour triggers the authorization alert.
Apple (Eskimo on the Dev Forums) released a FAQ providing more details around this alert:
https://developer.apple.com/forums/thread/663858
Particularly, providing more info as to what triggers this alert is FAQ-2:
https://developer.apple.com/forums/thread/663874
What operations require local network access?
The general rule is that outgoing traffic to a local network address
requires that the user grant your app local network access. Common
scenarios include:
Making an outgoing TCP connection — yes
Listening for and accepting incoming TCP connections — no
Sending a UDP unicast — yes
Sending a UDP multicast — yes
Sending a UDP broadcast — yes
Receiving an incoming UDP unicast — no
Receiving an incoming UDP multicast — yes
Receiving an incoming UDP broadcast — yes
These TCP and UDP checks are done at the lowest levels of the system
and thus apply to all networking APIs. This includes Network
framework, BSD Sockets, NSStream, NSURLSession and WKWebView, and any
other protocols that you layer on top of those.
IMPORTANT Receiving an incoming UDP multicast or broadcast does not
currently require local network access but, because we hope to change
that in a future update, our advice right now is that you write your
code as if did (r. 69792887, 70017649).
Resolving link-local DNS names (those ending with local, per RFC 6762)
requires local network access. Again, this check applies to a wide
variety of APIs including <dns_sd.h>, <net_db.h>, Network framework,
NSStream, and NSURLSession.
Finally, all Bonjour operations require local network access:
Registering a service with Bonjour — yes
Browsing for Bonjour services — yes
Resolving a Bonjour service — yes
Again, these checks apply to all APIs that use Bonjour, including
<dns_sd.h>, Network framework, NSNetService, and Multipeer
Connectivity.
Note You must declare the Bonjour service types you use in your
Info.plist. See How do I map my Multipeer Connectivity service type to
an entry in the Bonjour services property? for details.
Bonjour-based services where you don’t see any details of the network
do not require local network access. These include:
AirPlay — no
Printing via UIKit — no
One of my apps was triggering this prompt unexpectedly in our internet multiplayer mode. We use RakNet for our networking (which is a C++ lib that uses BSD sockets to send/receive UDP) and I was able to track the problem to the RNS2_Berkley::BindShared function here.
After creating a UDP socket, RakNet tests health/validity of the socket by having it send a little test packet to itself. iOS 14 was flagging this send-to-self behaviour as communication on the local network. I'm not sure if this send-to-self behaviour is a common pattern in socket programming, or a particular quirk of RakNet. Frustratingly, the OS prompt didn't actually appear until later when the socket was used for real which made the issue very hard to track.
I think that this is a false-positive from the OS and raised it with Apple (FB8802121). I won't be holding my breath though so I've just disabled that RakNet behaviour for iOS and am hoping that it wasn't too important.
Edit: To more directly answer the original question: sendto is a method call that can trigger this prompt.
I get rejected from apple app review for this alert. I'm using GCDWebServer which creates an embedded http server in my app.
I think I should provide a message in info.plist to tell user what my app want to do. Before I didn't set the text string in it.
And I would like to update if this will pass the app review.
<key>NSLocalNetworkUsageDescription</key>
<string>xxx uses the local network to connect with devices around you.</string>
Regarding iOS 14: permission request: would like to find and connect to devices on your local network and after numerous deploys to my physical device, I have figured out what causes this in my case.
I have a Xamarin.Forms app which
calls localhost:xxxx to do some local logging while I develop
I use a product thats called LiveSharp that does local hot reloading for XAML AND C# code changes.
So Livesharp actually communicates with a server on my localhost as well.
After disabling both of these and a fresh clean install on my physical device, the permission request has GONE .. Yay
Note: I had to completely remove LiveSharp nuget packages from my project.
Also I tried to re-enable my localhost logging, and for some reason the permission request does not appear.. :headscratch
So: remove any localhost communication that happens in your app. Or at least put an if statement around it allowing it if set to true in appsettings
I also have a Xamarin app and I used the package LiveXaml. After removing it the message was gone.
I'm using NSNetService and NSNetServiceBrowser to publish and scan for Bonjour services on the network. The implementation is working fine, the services are found on the network and they are capable of communicating. I'm currently trying to understand the framework's lifecycle and this what I've got so far:
// Scanning
netServiceBrowserWillSearch:
netServiceBrowser:didFindService:moreComing: // The device finds itself
// Advertising
netServiceWillPublish:
netServiceDidPublish:
This happens if I start the services with the adapter on. Now I need to know, at all times, whether the service is being actively advertised on the network; that is, if other devices are capable of finding it. So I test it with turning the Wi-Fi adapter off:
netServiceBrowser:didRemoveService:moreComing:
netServiceBrowser:didFindService:moreComing: // The device finds itself again, even after the adapter is turned off
Then I turn the adapter back on:
netServiceBrowser:didRemoveService:moreComing:
netServiceBrowser:didFindService:moreComing: // Yet again
The problem is that there is absolutely no difference in turning the adapter on or off, so I can't look for a pattern. Is there any other way that I can catch these events?
Edit: It gets worst. Even if I start the services with both adapters off (airplane mode) netServiceDidPublish: still gets called. So far it seems that netServiceDidNotPublish: is called only when I try to register the same service twice. This is very counter intuitive to me; maybe the service got published to the adapter, but not the network, and as such these callbacks are very misleading. At this point there is no way I can know whether the service is visible on the network.
For future reference, I needed to use workarounds to solve this. The problem is that Bonjour publishes its services to the protocol stack, so the adapter never gets queried for state. This makes sense, as Bonjour is a multi-transport protocol. In order to solve this I used an adaptation of Apple's reachability framework to listen to adapter state changes for Infrastructural Wi-Fi, at which point I query the adapter for the presence of the adwl0 interface for Wi-Fi direct support. Important note: that article claims to find support for general Wi-Fi connectivity which is not true; the awdl0 interface is the Wi-Fi Direct interface, which is why this will fail in devices such as the iPhone 4/4S. This is OK, because those devices do not support Wi-Fi Direct. As Bonjour also works with Bluetooth, I use CoreBluetooth to listen to Bluetooth adapter state changes. Although this framework is meant for Bluetooth Low Energy, I believe the Bluetooth adapter being on is a strong assurance that the Bonjour services are visible on the network. It's a bit unfortunate that Apple doesn't allow doing this without workarounds, but that's what we get, I guess.
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
Is it possible to build a socket connection between 2 iOS devices connected to the same network (Without net)?
if it's possible .. Is (CocoaAsyncSocket project) useful for me?
I just want to send a message from Device A to Device B which put the app in background .. when Device B receive the message should show notification to return the app to foreground.
It's not for the App Store, so I don't care if Apple would reject the app because of this behavior.
Yes, you can do it, and yes, CocoaAsyncSocket would be useful. If you don't have to worry about the carrier network's firewalls and filters, then you should certainly be able to build a client-server app running on two iOS devices. One opens the server socket to listen, and the other one (the client) connects, via the Wi-Fi network.
Trying searching on Google (e.g. "CocoaAsyncSocket iPhone iOS site:stackoverflow.com") or directly here on Stack Overflow.
Here's somebody who seems to have accomplished this
Another link
And a post from Robbie Hanson himself, referring you to the EchoServer projects in the github repository
EchoServer project
You may have to use a static IP address for the server device (I'm not sure how much control you have over the Wi-Fi network's configuration), or use some other mechanism for letting the two devices discover each other.
I am working on a web application for iOS that is going to be accesed from a local webserver in a network that has NO internet connectivity at all.
My problem is that everytime an iOS device is locked, it disconnects from the WiFi network, so when the device is unlocked again, it has to reconnect. Part of that reconnection process is determining if there is Internet connection (which there isn't). Until the process is not finished iOS does not allow any DNS resolution (so if I write http://10.0.0.1 it will go there, but not if I request http://something.local.com).
Since we control that network, we want to know how to does iOS verifies Internet connectivity so that we can fake the responses it expects.
I don't know if it's possible to resolve DNS without an internet connection on iOS, but if that's the case, that would be a way better solution since you don't need to mess with your router settings. Use my solution only if it really isn't possible with only code.
I'll suggest you to follow this guide: http://blog.jerodsanto.net/2009/06/sniff-your-iphones-network-traffic to check which actions your iPhone executes to detect an internet connection.
Using this information you could forward the is-there-internet-requests on your router to a local server which fakes the there-is-internet-responses.
This assumes Apple really uses an external server to detect this, which I'm not sure about. But it wouldn't hurt to give it a try!
Have you looked at the Reachability Class? You don't have to use the reachabilityForInternetConnection method, which checks if a default route is available. You can use the reachabilityWithAddress: method and check if your server is reachable.