2

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. :(

TealShift
  • 842
  • 5
  • 19
  • How about if you get the error, just rescan again anyway. Eventually they may connect to the network. Or display a message to use the user and when they tap "retry" you retry – Paulw11 Aug 25 '16 at 21:20
  • @Paulw11 That was actually my first method of error recovery, but I learned that wasn't appropriate when I got an immediate error, which caused a tight loop. A cheap workaround is to use an additional check on how long ago I scanned. – TealShift Aug 25 '16 at 22:26
  • I should also mention this is a completely automatic background process. – TealShift Aug 25 '16 at 22:34
  • The standard approach is called exponential back off and is used to avoid tight loops. If you get a failure you re-try after, say 5 seconds. If you get another error then re-try after 10 seconds, then 20 seconds, then 40 and so on. You might like to set a upper limit so that you don't wait longer than 60 seconds or so before trying again. – Paulw11 Aug 25 '16 at 22:45
  • I understand that. But from what I've gathered the service discovery framework in iOS is fully featured, so I shouldn't have to or want to reinvent it. – TealShift Aug 25 '16 at 22:51
  • As far as I am aware the only service that is available is `SCNetworkReachability` - This can give you a callback but it is based on monitoring a specific host or IP address to determine reachability, not just network connectivity which is what you want. I don't know if you can use it to monitor reachability of an MDNS name. You could try – Paulw11 Aug 25 '16 at 23:27
  • Actually, the solution is listed in the Readme.md right after the section you quoted: *Apps that have a specific requirement can use reachabilityWithAddress to monitor IN_LINKLOCALNETNUM (that is, 169.254.0.0).* – Paulw11 Aug 25 '16 at 23:31
  • Yes, thanks for reminding me about that! I actually tried using reachabilityWithAddress, but it requires this c struct that recently changed from sockaddr_in to sockaddr so my attempts to find a single example of using IN_LINKLOCALNETNUM have failed. Using C makes me want to hurl my macbook. :U – TealShift Aug 26 '16 at 00:12
  • The reason I didn't mention that in my question was because the ReadMe doesn't seem to recommend that method for Bonjour. – TealShift Aug 26 '16 at 00:18
  • It isn't particularly clear language but I read it as "this approach isn't recommended in general but if you specifically need the link local detection that was provided by reachAbilityForLocalWiFi this is the technique you can use." You can just pass a sockaddr_in to `reachabilityWithAddress` - See http://stackoverflow.com/questions/9393645/reachabilitywithaddress-error-giving-it-an-ip-address for an example – Paulw11 Aug 26 '16 at 00:20
  • 1
    As I mentioned that method now takes _sockaddr_ instead of _sockadd_in_ and troubleshooting C code was something I was hoping to avoid. It's so frustrating I'd have to post another question for the exact code if I were to take that route. :f – TealShift Aug 26 '16 at 00:32
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/121875/discussion-between-paulw11-and-tealshift). – Paulw11 Aug 26 '16 at 00:32

0 Answers0