I'm working on an embedded device that will communicate with (WiFi-only) iPads over WiFi. However, these devices are not connected to the internet. They are simply connecting to a specific port, which is constantly relaying certain information. The iPad connects to the Access Point, receives an IP Address from DHCP, and can now reach the desired
What I'm seeing is frequent disconnects, or interruptions in the connection.
My suspicion is that iPad's inability to connect to captive.apple.com/library/test/success.html is causing it to either re-scan for WiFi networks or in some other way momentarily disrupt the connection.
Is there a way to disable this behavior, or ensure that an iPad remains connected to the intended WiFi, even in the absence of an Internet connection? Either through a setting on the iPad, or a configuration setting on the embedded router/Access Point?
If you don't mind breaking backwards compatibility with older iOS devices (iOS 3, for example), I'm told (by someone in DTS, IIRC) that you can send a DHCP advertisement without a router advertisement field, and iOS will do the right thing. I have not tried this personally, though.
You might also try using the CaptiveNetwork framework (deprecated in iOS 9 with no replacement) to claim control over the SSID, and the just never report success or failure. I'm not sure if that would work or not, but it is worth a shot.
Related
I have a peripheral (using CSR1010's) that only is able to connect to the iPhone if it advertises with Gap settings "Bondable Mode". For my application, I don't want the phone to bond to the device, but do still want to pair (have a secure connection).
If I put the server in non-bondable mode, the iPhone drops the connection immediately after pairing is authorized without any action on the peripheral (i.e. it's the iPhone disconnecting).
According to the spec, non-bondable mode only means that regardless of how the connection is established (with/without pairing), the devices should not bond (retain that secure connection after this connection). I'm wondering if the iPhone actually supports this (spec says it's mandatory to support it).
No, that behavior you mention started to happen in iOS 9. Before that it worked fine. It's not standard behaviour but that's what apple does...
What do you want to achieve anyway? Using pairing without bonding does not add any security at all almost, since ble pairing can easily be decrypted.
I think it is not the issue of whether iPhone support the non-bond-able or not, it is the different device can choose the best security level for itself.
which means each device can choose the high security mode(which request peer device also need high security), or choose the lower one(which means he could not connect to higher security node). Regarding to your concern, if iPhone also use the non-bondble mode, that means it is meaning less for the high security level since even low security level device can interact with iPhone.
or we can say iPhone can support the mode that without pairing but does no employ it.
I have created an iOS VOIP app. The reason behind creating a VOIP app was to make my application run in background. Well that is working fine. I am also connected to a host through TCP/IP.
The problem here is when the OS is restarting the wifi radio automatically at some interval, which results in a disconnection. Then I have to reconnect.
Can anyone help me to understand what exactly is causing this behaviour?
There are a few things this could be. Firstly, are you running iOS 8? there have been some reported wifi issues with it. Just google iOS 8 wifi issues to see how many people are having similar issues.
Secondly, it's not too irregular for your wifi network to shuffle you around, so it could be either your wifi router itself, or the iPhone. I would probably try using manual ip allocation instead of DHCP on your router as a test.
Thirdly, your software obviously needs to be set up to handle dropouts etc - dropouts and package less etc are fairly common parts of any networking.
I'm really stuck with a problem, thus, needless to say, I need your help.
I'm using CoreBluetooth to communicate between two iDevices, it is the same app, running as a central on one device and as a peripheral on the other device. In some cases the central loses connection to the peripheral with the following error:
Error Domain=CBErrorDomain Code=10 "The connection has failed unexpectedly." UserInfo=0x14ee8fe0 {NSLocalizedDescription=The connection has failed unexpectedly.}
In this particular case, the peripheral was an iPad 4 and the central was an iPad mini.
I tracked down the problem and it turns out, that once I encounter this issue, the problem will persist every time I connect, regardless of restarting the app or even the bluetooth on both sides, HOWEVER, the interesting part is, if I turn off Wifi on the central device, the connection doesn't time out anymore.
Do you have any suggestions, workarounds? Both devices are running iOS 7.1.1
This is a well known issue, and it has a solution that is confirmed to work for the Mac side.
sudo defaults write /Library/Preferences/com.apple.airport.bt.plist bluetoothCoexMgmt Hybrid
After you run this script, the issue will go away and BT connections will remain stable.
And here is the explanation:
Background: after a lot of snooping and head scratching, here's what I found: the issue here seems to be that the system isn't using the same Bluetooth/Airport coexistance mode for BLE as it uses for BT Classic. One tell tale sign: if you have any BT Classic devices connected and active, the bug won't repro (neither for the Classic device nor any connected BLE device). The moment the Classic device disconnects, the bug repros (ie all the BLE connections are also dropped).
Further, I was able to find reference in the symbol table of an airport configd agent to an override setting for the coexistance mode. If you set the mode manually as above to 'hybrid' (the same mode that is usually invoked when a classic device is connected), the bug no longer repros.
All credits go to William Henderson from Knock for this trick.
There were cases when the same effect was perceived on iOS devices as well. This some times happens when the Core Bluetooth connections are not stable. Sometimes this can lead to the WiFi connection being unusable. But it's hard to reproduce, at least I wasn't able to, and your question does not concern it either.
My company is developing an iPhone accessory that requires a relatively high connectivity rate to the phone. Due to MFi limitations (USB 2 communications in HOST mode fair only around 100KBps), we're looking at hosting a WiFi ad-hoc network on our accessory, and connecting to that network with the iPhone's WiFi.
This could really work out great in many regards, except we can't seem to find an (Apple-approved) way to programmatically switch the iPhone's WiFi connectivity. Ideally the app would automatically connect to the accessory's network when visible, and then re-connect to the user's preferred network when not visible/needed.
We are aware of the MobileWiFi framework, which fits the technical bill, but won't pass Apple's approval process.
Can anybody suggest a way to achieve our goal? Perhaps there is a system model view that can be called up to allow the user to switch WiFi networks without directly using private APIs?
Creative solutions welcome!
Hate to say it, there's really no way to do it. I can think of two easy workarounds.
1. Make it available on Cydia for jailbroken devices. AirServer just did this.
2. Less elegant, have UIAlertView with a switch over to the wifi pane of the Settings app that is shown when the peripheral is connected and disconnected. A lot like the location settings prompt.
3. Make an Android app!
Apple, you're a pain in the ass.
Sorry to be the bearer of bad news, but the definite answer is no. The main problem with your approach wouldn't even be Apple's approval process, but the inability to access the Internet while connected to your device. iPhone doesn't even try using cellular data when connected to wifi, being that wifi connected to the Internet or not.
You could file a bug report requesting these features and pray Apple hears you which will probably never happen in this case.
I would suggest going bluetooth, but if usb is not fast enough for you, guess that's not an option either.
That pretty much puts you back to square one and going usb. Or distributing your app via Cydia.
I write an app that requires a persistent WiFi connection, and to facilitate that connection being as persistent as possible, I have UIRequiresPersistentWifi set to yes in my Info.plist, and I recommend leaving the app 'open' when the user presses the the hold button.
However, on iPod touches (I have a 2G one and a 4G one for testing) running iOS 4.2.1, the device seems to shut down the WiFi connection much earlier after the device is put to sleep than it did on earlier iOS versions. I think it's on the order of 60 seconds.
I don't believe Apple has made any firm commitments on how it handles powering down network connections, but I was under the impression it was longer, intended to be longer, and it was something we could rely on. Does anyone have any input on this?
It appears after some reading/research, it looks like Apple's philosophy is that the WiFi network shouldn't be relied upon: "Note: Note that even when UIRequiresPersistentWiFi has a value of true, it has no effect when the device is idle (that is, screen-locked). The application is considered inactive, and although it may function on some levels, it has no Wi-Fi connection." - (from the iOS Application Programming Guide).
I'm guessing I'm seeing the different behavior on an iPhone because, also, in the iOS Application Programming Guide - "Connect to the network using the Wi-Fi radios whenever possible. Wi-Fi uses less power and is preferred over the cellular radios."