I’m not talking about Reachability.
What I’m talking about is figuring out how to create a network connection from an iOS device across the cellular interface.
Why? Because I have conditions where the device connects to a WiFi access point so it chooses WiFi… but that access point is not internet connected and goes nowhere. I have data which I must make every effort to deliver and it some cases it’s getting lost in the WiFi gateway to purgatory. In both cases of using Reachability and relying on MPTCP, Apple has already given priority to WiFi in the stack.
I know NSURLSessionConfiguration can set allowsCellularAccess to allow cellular access — I’m looking to require cellular for the routing.
Even at the CFNetwork level I’m looking at kCFStreamPropertyConnectionIsCellular for status, kCFStreamPropertyNoCellular to disable cellular.
I can’t find anyway to give preference to the cellular radio. I realize Apple has gone to great lengths to prefer WiFi and I’m going against that — which is why I’m having such difficulty finding an answer to this.
I'd like to keep this up in the Cocoa level, but not opposed to going into Foundation or deeper levels. I would like to avoid trying to parse an interface table (if it's even accessible) to figure out which is the cellular interface.
Has anyone successfully created a network connection across the cellular link despite WiFi appearing to be present?
Is some configuration of Multipath TCP the answer here?
To bind to a particular interface, as far as I'm aware, you'd have to drop all the way down to the raw socket level, and there's no way to provide a custom socket for NSURLSession purposes, so you'd basically be rewriting it from scratch. You should file a bug asking for support for binding an NSURLSession to a source IP.
The behavior you're experiencing is a known problem with iOS and disconnected networks. iOS 9 and later do a better job, but even then, they can be highly problematic; the devices sometimes refuse to talk to the Wi-Fi network, and sometimes refuse to talk to the cellular network. Specifically, it seems to fail spectacularly if either signal is weak. Just this morning, I actually had to force my iPhone (iOS 10) to talk to a disconnected Wi-Fi network by putting it in Airplane mode and enabling only Wi-Fi.
I'm told that you can fix this by configuring the network's DHCP server to not provide a router advertisement; that said, every time I've tried that, the iOS device would just keep asking for an offer repeatedly. Maybe that bug got fixed at some point. If so, it might be worth a shot, but don't expect it to work in older versions of iOS.
Failing that, assuming you don't need to support web browsers in iOS 3 and earlier, you might try eliminating the DHCP server on that Wi-Fi network entirely, and just rely on DNS service discovery with zero-conf IPs. That way, the device won't see a router, and it won't try to send data out that interface except to those link-local IPs.
If that isn't possible for some reason, ordinarily I would suggest using a customized copy of libcurl, except that I doubt this will work in your case, because POSIX networking doesn't wake the cellular hardware.
In iOS 12 and later you can use the Network Framework. Sample code is here.
Related
I'm most likely not using the correct terminology in my question.
Is it somehow possible for an iphone to receive an "audio stream" from other iPhones over Bluetooth?
The idea is to make an app that makes it possible to listen to the music libraries of other iPhones in the Bluetooth range. All while not having access to the internet and not needing to pair up and transfer the actual song onto the phone.
The thing you ask of is doable, but is not something trivial. Bluetooth communication can be implemented to work like a TCP/IP socket implementation, the only problem is, there is no actual protocol to follow. Usually the apps that implement bluetooth communication use they own protocols definitions in order to serve the purpose of the app.
There are several steps that have to take in consideration:
The transfer speed over bluetooth, it's not fast but it's not slow either, the main problem with the transfer over bluetooth is that you have to implement the data transfer, for example in TCP/IP the whole package exchange (send/acknowledge/receive) is done by the system, there's no general protocol implementation to do such thing using bluetooth.
The connection handling, this is something really tricky depending on OS & OS version, especially on iOS the connect/disconnect handling is clumsy & often buggy.
Security, without pairing and bonding there's no security. Even with pairing & bonding the security is flacky. Without security you might get your app hammered down and bricked by a simple bluetooth sniffer.
Other apps that use bluetooth, for IoT or other gadgets this is not an actual problem, but when you have a client/server like approach via bluetooth using two mobile phone you might get in trouble because of other apps that wrongly use the bluetooth (don't close connections, try to scan to frequently) and you can't do anything about it.
These are the things that cross trough my mind about the bluetooth communication, I've worked on several apps that connect to IoT and I can tell you it's not something trivial to implement. You get a lot of headache for things that you can't imagine.
As an alternative you could use WI-FI without internet connection, there was a trending post some time ago about Mesh Networks that use only the WIFI signal to transmit data, not even actual wifi network, worth checking out IMO.
I have couple of URLs that has to be called(programatically) through wifi not with mobile data.
As WIFI ASSIST is on , whenever the wifi is weak ,packets get transferred through Mobile data.
I would like to stop this from happening.
As far as I have researched, there is no API to toggle wifi assist switch on and off programatically
I can find if the user has mobile data and wifi on with the help of Reachability Class I believe and I can alert the user to keep wifi assist off but this is a very bad user experience.
so I decided to look if its possible to be done with the help of iOS mobile configuration file.
But I couldn't find any keys related with wifi-assist in Apple configuration profile reference.
so I am wondering , is it possible to force wifi to be used for certain URLs.
I remember this is possible with VPN ON DEMAND we can have certain domains to be accessed via VPN.
I am wondering if same is possible for wifi as well through configuration profile
Any suggestions are welcome.
As others have mentioned, there is no way to do manipulate this setting programmatically in iOS. This is not really what you are asking, as you seem to already know the answer to this is "No".
You are asking about the configuration profile, so I am assuming these are managed devices. Unfortunately, there is no configuration profile payload I am aware of that forces the managed devices to disable Wi-Fi Assist.
Your intent, however, is a bit different than what is being asked, I believe. I think you basically have an app that communicates with a resource that is only accessible via the Wi-Fi network (likely a corporate Wi-Fi network). If the app tries to connect to the resource while on cellular, it will not be able to connect. In some cases, when the Wi-Fi signal is weak, the device tries to be helpful and switches to cellular, causing issues with the app. If we could figure out a way to force iOS to not take advantage of Wi-Fi Assist when your app is running, you would be in good shape.
If you can install this app as a managed app, there is a way to identify that the app should only be allowed to run on a Wi-Fi connection. Setting the network usage rules AllowCellularData to false should do this (see this for more details). The thing I am not sure of with this solution, is whether this simply causes the connections to fail when Wi-Fi Assist is on and active, or if it makes iOS prefer to not use Wi-Fi assist when the app is running because it cannot connect over cellular. So I think you can tell an app to only connect over WiFi, but it doesn't really give you a better solution to your user experience problem. The only think it really buys you is that your app connection won't ever try to connect when connected to cellular. There is a chance, however, if you change this value to false for your app bundle ID, it will prevent Wi-Fi Assist from enabling when your app is running. I don't have access to MDM to try it out, but you could test and see.
Ultimately, given that this is probably a corporate device situation, I think you are going to have to address this through user training. The good news is that this is a one-time step. Sure, users may have slight degradation of network performance when Wi-Fi signal is weak but cell signal is strong. This does not matter as much if these are corporate devices where the corporate apps will mostly work only on the company's Wi-Fi network.
Another solution is what you mentioned, basically using on-demand VPN to provide a connection to the internal resources. This is additional infrastructure work, and you already mentioned it, so I'm not sure if it is even an option.
Obviously, the other solution would be to expose the network resources through your firewall, which could allow you to access it over cellular. I'm suspecting this is not possible due to security constraints.
Unfortunately, there are not a lot of good options in this space. However, have hope that there is some way to do it, as Sonos appears to have done something to
allow their app to avoid switching to WiFi Assist while streaming to a local network resource: https://sonos.custhelp.com/app/answers/detail/a_id/4257/~/wi-fi-assist-and-sonos
I wonder if you could have your app open a streaming audio connection to a fixed local network resource, which would cause it to use Wi-Fi. It's a pretty crazy hack, but with a low enough bitrate audio file streaming, it might do what you need while not eating up too much of the network throughput.
Per Apple's notes on Wi-Fi Assist:
Wi-Fi Assist won't automatically switch to cellular if you're data
roaming.
Wi-Fi Assist only works when you have apps running in the
foreground and doesn't activate with background downloading of
content.
Wi-Fi Assist doesn’t activate with some third-party apps
that stream audio or video, or download attachments, like an email
app, as they might use large amounts of data.
Of course the other possible solution that you could consider is improving your Wi-Fi coverage to that the signal doesn't get bad enough for Wi-Fi Assist to be needed. I know this may not be feasible, but wanted to put it out there.
Good luck with this!
There is no public API that allows you to enable/disable "Wi-Fi Assist", and even if you find a way to do it your app will be rejected.
No you can not enable or disable WiFi by programmatically and there is no API for this.
I have just delivered a prototype for a big client, everything was fine but I'm now curious to know if the solution/architecture I've chosen was the right one or there's place for improvement in case the project will keep on.
The task was to build two iOS apps: one running on 5 different iPhones, and another running on 2 iPads. Basically the iPhone applications had to communicate information to the iPads, and occasionally they also had to send information between each other (iPhone to iPhone). All the infos where small JSON objects/chunks whose size was small, really small.
The app was not intended to reach the app store, is a working prototype to test out some ideas in a user testing environment.
I discarded bluetooth because we are talking about a peer-to-peer communication, not a one-to-one.
What I did was to use web sockets thanks to SocketIO, through a small Node.js server that was running on my mac. The server was really simple, just receiving the messages from the clients and broadcasting information to the other ones.
What do you think? Is the solution I've chosen ok, or there are better ones?
For example, this morning I've just found out these thread here on SO, and I've discovered I could have used GameKit. What do you think?
Socket.IO is nice because it is fairly simple to implement but it has the downside of requiring a central server. If you wanted to avoid that, you could use the Multipeer Connectivity framework that was introduced in iOS 7.
It will let you create one-to-one communication channels between devices on either the same WiFi network or Bluetooth. Once the channel is created, you can send whole NSData objects (or create streams but it doesn't seem relevant to your use case).
A good read : http://nshipster.com/multipeer-connectivity/
The WiTap sample from Apple demonstrates peer-to-peer networking over Wi-Fi and Bluetooth. Using Bonjour, the application both advertises itself on the local network and displays a list of other instances on the network. Supports infrastructure networks, peer-to-peer Bluetooth, and peer-to-peer Wi-Fi (on compatible hardware).
I have personally tested it and it works fine and well documented.
I think socket.io is the best choice. It is built on top of engine.io (which in turn is built on the fastest websocket implementation: ws) It has oldest to newest fallbacks, so it starts with long polling and works its way up. This guarantees a quick initial connection instead of needing to poll the device for features. You can read more on this here. Best of all, it handles everything seamlessly. You write your code as if websockets are supported on connecting devices and if not it will use other methods behind the scenes.
This post details many of the websocket libraries you could use with your server. Which websocket library to use with Node.js?
I am convinced Bonjour is the best solution:
Apps can also leverage Bonjour to automatically detect other instances
of the app (or other services) on the network.
However I've never used it myself; perhaps someone who has can comment?
I'm trying to find out what AWDL is. On iOS, if you use Apple's peer-to-peer networking over BlueTooth, it seems Apple creates a new Network Interface "awdl0" to implement (I guess) IP-over-BT.
But I can't find any docs on this tech, or this interface, how it behaves, things we must / must not do with it, etc. Google comes up blank :(.
In particular, I believe it means "established a BT connection, and I'm running an IP bridge over the top, and you can use this to communicate peer-to-peer". Apple's own system libraries have bugs where this bridge isn't setup quickly enough, and if you send data too soon, it appears to get dropped by the OS. So ... if I can query this awdl0, I hope to check "are you ready yet?" and delay P2P messages until the OS is happy.
UPDATE
More info: I can get pairs of iOS devices to create awdl0 connections to each other - but they never get created to OS X machines, whether BT and Bonjour are on or not, whether the devices are paired or not.
Some background:
In iOS5, Apple permanently disabled the Bluetooth parts of Bonjour/Peer-to-peer networking, and published a technote instructing everyone to use DNS-SD if they wanted to keep using Bluetooth as a transport between iOS devices. This is fine, but it means you must use DNS-SD if you want high-performance BT, and you want it reliable.
(GameKit sometimes works fine, but we often see terrible performance in real-world scenarios, e.g. crowded public places - which goes away if you use DNS-SD)
DNS-SD protocol doesn't include info to tell you what the hardware is using. But it does tell you the Network Interfaces (which is how I know we're running on awdl0)
DNS-SD is awesome, and we have high-speed, low latency connections peer-to-peer between iOS devices - all the stuff that GameKit promises but often fails to deliver whenever there's more than a few wifi/BT devices in range.
AWDL recently caught a lot of attention when it caused Wi-Fi issues in iOS 8 and OS X Yosemite devices.
What is AWDL?
AWDL (Apple Wireless Direct Link) is a low latency/high speed WiFi peer-to peer-connection Apple uses for everywhere you’d expect: AirDrop, GameKit (which also uses Bluetooth), AirPlay, and perhaps elsewhere. It works using its own dedicated network interface, typically “awdl0".
While some services, like Instant HotSpot, Bluetooth Tethering (of course), and GameKit advertise their services over Bluetooth SDP, Apple decided to advertise AirDrop over WiFi and inadvertently destroyed WiFi performance for millions of Yosemite and iOS 8 users.
How does AWDL work?
Since the iPhone 4, the iOS kernels have had multiple WiFi interfaces to 1 WiFi Broadcom hardware chip.
en0 — primary WiFi interface
ap1 — access point interface used for WiFi tethering
awdl0 — Apple Wireless Direct Link interface (since iOS 7?)
By having multiple interfaces, Apple is able to have your standard WiFi connection on en0, while still broadcasting, browsing, and resolving peer to peer connections on awdl0 (just not well).
You can find more info here and here.
I'd like to provide a more precise answer as to how the protocol works internally. I quote part of the abstract of this paper.
In short, each AWDL node announces a sequence of Availability Windows
(AWs) indicating its readiness to communicate with other AWDL nodes.
An elected master node synchronizes these sequences. Outside the AWs,
nodes can tune their Wi-Fi radio to a different channel to communicate
with an access point, or could turn it off to save energy.
From a user perspective, AWDL allows a device remain connected to an infrastructure-based Wi-Fi network and communicate with AWDL peers "at the same time" by quickly hopping between the channels of the two networks (AWDL uses fixed social channels 6, 44, and 149). In contrast to the previous answer, we found that current versions of AWDL work fairly well and channel hopping only induces a small overhead.
Disclaimer: I'm co-author of this paper and we retrieved this information by means of reverse engineering. If you are interested in the details, please read the paper and have a look at the Wireshark dissector (published soon).
I have a situation where I would like to communicate between 2-4 devices over the 3G network (it should also work over WLAN, but 3G solution is critical).
Every device (except one) asks for a GPS-location every ~5 seconds, but when this process is cancelled by the user of that device, one device needs to be informed of this event.
I was thinking that one device could act as a server, and the rest as clients that should connect to the server. Is this possible over the 3G network?
I've also read about push-notifications, is this relevant here? Can you receive notifications without disturbing the user with a popups etc?
Are there other ways?
Basically I would like to use apple "standard" solutions (if there are any) before diving into eventual socket-programming or anything similar...
What I would like to avoid is to have a webserver or some similar "3rd-party" solution, because I don't want many users to simultaniously connect and "pull" from the same external server in a final solution...
UPDATE:
Basically my application will have thousands of users that will need to be informed if an even occurs. Also this happens simultanously ~5 second, what would be the best solution to reduce load and avoid spamming?
I was thinking that one device could act as a server, and the rest as
clients that should connect to the server. Is this possible over the
3G network?
It could work, but having a dedicated server would be a better choice
I've also read about push-notifications, is this relevant here? Can
you receive notifications without disturbing the user with a popups
etc?
In your case no, since you will need a server to communicate with apple
Basically I would like to use apple "standard" solutions (if there are
any) before diving into eventual socket-programming or anything
similar...
There are no standard solution, other than you should probably rethink about using a dedicated remote server for this
iPhones can't communicate directly with each other using 3G. You can access the internet through the 3G, but you can't do peer-to-peer as you are suggesting. If you were close enough, you could use bluetooth, but I expect you are too far away.
You would have no way of detecting the one device that acts as a server from the other devices. The IP address could (and probably would) change every time the device connects to a mobile data network. You would need a central server to co-ordinate all of the clients.
You have multiple questions, but I'll try to address as many of them as I can:
I was thinking that one device could act as a server, and the rest as
clients that should connect to the server. Is this possible over the
3G network?
No, you cannot run a server on a iPhone/iPad that is accessible over 3G without an external website acting as an intermediary. (You can run one that is accessible over Wi-Fi, but this does not solve your problem as stated.)
I've also read about push-notifications, is this relevant here? Can
you receive notifications without disturbing the user with a popups
etc?
Push requires you (or a third party contracted by you) to have a web server, so if you want a server-free solution it is not relevant here.
Are there other ways?
Over 3G you will, under the current Apple restrictions, always need an external server.
Basically I would like to use apple "standard" solutions (if there are any) before diving into eventual socket-programming or anything similar...
Diving won't help you here. Even using low-level socket programming you will not be able to run a server on an iPhone accessible over 3G without an external website to aid in establishing a connection.
You can try using GameCenter. The mechanism of network games in Game Center allows connect up to four players with no third-party solutions.