i am programming for google android and i wonder if the scans for wireless 802.11 networks are done passively or actively? i mean: does the device actually emit a beacon request signal on WifiManager.startScan() or does it just listen for beacons sent periodically by the access points?
Android does passive scans, it listens for beacons. Doing an active scan can create a lot of congestion on the network by sending out probe requests and waiting for probe responses.
Even though this question is 11 years old, it still has relevance today and so I thought I'd give it an up-to-date answer:
Yes, Android devices do search for APs actively. Passive scanning requires for the device to listen for beacons for a longer time, which is energy consuming see this paper by Freudiger for more details
Active scanning only requires sending probe requests and then waiting for the reply on the corresponding channels. This takes less energy as it requires for the radio to be turned on for a much shorter time span. Unfortunately, active scans require for the device to identify itself somehow, and this makes it easily trackable. Mitigations in place are e.g. MAC address randomisation with every burst, randomised MACs during connection with an AP, randomised Sequence Numbers, omission of unnecessary fields and more. It all doesn't seem to be enough as people still find way to optimise their algorithms to improve tracking via Probe Requests. ;-)
Rain Ma replied that Probe Requests contain SSIDs, this is technically not true for all devices anymore. The only reason for SSIDs in Probe Requests is to find hidden networks. In Android devices, newer OS versions don't transmit SSIDs at all anymore, save for when scanning for hidden networks. Up until Android 8, all manually added networks were automatically assumed to be hidden networks. Starting with Android 9, one has to explicitly mark a network to be "hidden" for the device to probe with SSID.
iOS does automatic detection of hidden networks, and they say they don't probe with SSID at all unless they detect a network to be hidden.
The answer is YES
Actually, using omnipeek to capture packages from Android/iOS devices, we can get the result below:
Most Android devices always try to send Probe Request Frame every few minutes. They keep a list of SSID you used to connect, and always try to send probe request frame with SSID to see if they are available now. I guess one of the reason is 802.11 pre-authencation , and some other reason may be: enhance the wifi list display speed.
They are working in a active.
iOS devices seldom do active scan
If you wanna konw more about the rules, you'd better read "802.11 Wireless Networks The Guide"
You can refer to the pciture : Packages captured by omnipeek
Related
Nearby Share sometimes uses bluetooth to transfer the files because of which it is very slow. Sometimes it is not at all handy to transfer files that are more than 100 MB. Initially I thought Bluetooth is used only for handshaking purposes. But later I realized that the files are itself transferred via bluetooth. I'm curious to know why should the files be transferred via bluetooth when it can be transferred via wifi direct. A lot of third party apps including Google Files use wifi direct to transfer the files. So why does a built-in functionality like Nearby Share should use bluetooth. The sole purpose of Nearby Share itself is to achieve fast file transfer with wifi direct and without internet. So if the files are transferred via bluetooth there is no point in using Nearby Share.
I'm also curious to know the various modes of file transfer present in Nearby share. There are three modes: Data, Wifi Only and Without Internet. I'm really curious to know why is an internet connection required to transfer files when Nearby Share is meant for file transfer without Internet. Is it meant for handshaking purposes in Web RTC?
(Disclaimer: I work on Nearby Share)
Nearby Share will always attempt to upgrade to WiFi before sending files larger than 1MB. A grace period of 10sec is given for that upgrade before fallback mechanisms kick in and the file is sent over Bluetooth as a last resort. Even after falling back to Bluetooth, the devices will continue to attempt to upgrade to WiFi in the background, but some failures are unrecoverable and the file will fully send over Bluetooth. Note that urls and very small files will immediately send over Bluetooth.
This upgrade can fail for a multitude of reasons. Most commonly, it's a concurrency issue. The same radio is used for Bluetooth, p2p WiFi, and your normal access point connection and it must be time-shared accordingly. If all 3 want to be on different channels, you will miss messages -- it's a guarantee. If these messages are important, such as the authentication frames when connecting over WiFi Direct, then the connection will fail. If these messages are less important, they may be resent until successfully received, but it will lower throughput for the transfer such that even 5GHz WiFi can look to be as slow as Bluetooth.
Nearby Share tries to avoid this in a few ways. When regulations allow, we will attempt to start the WiFi Direct group on the same channel as the access point. This way, the phone doesn't have to timeshare (although it does have the side effect of colliding with messages from the access point. But generally, both sides will back off a random amount and retransmit, and the loss is less than the loss of multi-channel concurrency). Unfortunately, many countries do have regulations that allow certain (or all) 5GHz channels only indoors -- in those cases, the access point can be set up to utilize it but WiFi Direct cannot.
We also prefer mediums like WiFi Direct over Hotspot, as WiFi Direct commonly uses CTS2SELF frames to advertise "Do not transmit for this duration". Unfortunately it's not as straightforward a message as "I am going off channel, do not try to communicate with me" -- CTS2SELF has the side affect of quieting all communication over the access point even if it wasn't directed to the phone -- but it does get the point across.
We pause any Bluetooth activity we have control over, to reduce the need to timeshare with it. In some severe cases, where the OEM has implemented timesharing that's too aggressive, we will turn off the Bluetooth radio to forcefully interrupt Bluetooth activity, but this is disruptive and usually a bad user experience.
We may try to send the data over your access point itself instead of setting up WiFi Direct. This can avoid the MCC situation described above, but comes at the cost that the data needs to be re-encrypted (because we don't know what other devices are connected over LAN and might be eavesdropping), and it does introduce another hop, as the data needs to go through the AP even if the devices are side-by-side. TDLS helps avoid that last issue, but it has limitations (eg. it won't use 40/80/160MHz bandwidth if the AP isn't set up for it, and it'll send over 2.4GHz if the AP is on 2.4GHz).
Other possible failures include the device getting into a bad state (toggling airplane mode can help here), the Android version being too low (ideally both devices should be R+, as it's almost impossible to fix bugs on older Android OS versions, even though we try), or just bad luck.
I'm trying to setup a communication channel between two Android phones.
Unfortunately, Google decided to block developer access to Bluetooth adapter MAC address, effectively disabling the entire NFC to Bluetooth handover process (Simple Secure Pairing).
Side note: why? privacy/security gain is minimal to none, especially
if you randomize it! you could simply randomize it when an app requests the MAC and that's it!
This SSP process used to take roughly 1-3 seconds at max and generated great user experience.
Currently, I'm stuck with NearBy which generates a terrible user experience (who's gonna wait 10 seconds just for the initial connection?)
The only options we have left:
Improving NearBy API somehow (~10 seconds average to discover and connect! why Google, why?)
WiFi hotspot - setting an agreed-upon ID as the name, discovering and connecting (~8 seconds average)
Bluetooth - requires a popup to be approved each time, a bit faster but results in bad UX.
Internet - just use the Internet and fall back to local wireless methods (when 4G internet connects much faster than local wireless Android NearBy, you know Google has definitely failed with the implementation).
Is there some secret sauce I can pour onto NearBy to improve it, to be, at least as fast as Apple AirDrop (~4 seconds average)?
Do I have any other options I'm missing?
Thanks!
The definition of absurdity:
Two phones that are 1 meter away from each other with several direct wireless options (Bluetooth/BLE/WiFi) take an average of 10 full seconds just to connect (before data is sent).
Two phones that are 20km away from each other, communicating over cellular data (3G/4G/5G) fully connect after an average of 1.7 seconds! Even after traveling through GSM BTS, proxies, cache, firewalls, BGP routing and other filters.
Google has to do something to fix that (after they disabled the only method to make this faster, using BT SSP, handing over NFC to BT - as they disabled BT MAC address exposure).
My solution right now is to use Internet by default while simultaneously trying to connect via NearBy, as I need a fallback ready to work for some of my clients that don't have a good cellular signal.
I'm working on an Android app that needs to detect if other users of the app are close to each other (lets say within the same room or Bluetooth range). The app needs to be able to detect this without any user interaction.
Geolocation is not an option as this is too inaccurate indoors.
The app runs only on company owned phones that stay on company ground, privacy is not a concern.
All devices are always connected to the same wifi network and BT is always enabled.
My idea is to detect if users are within a close distance of eachother by periodically Bluetooth scanning and checking the results against a list of MAC adresses that contain all the devices that have the app installed.
The MAC adresses of all devices are send to a server, the devices then grab this list of mac adresses from the server to compare to the results of a BT scan.
Problem is, BT and Google's seem to use Advertisement / Discovery patterns where one device acts as the server and one device acts as the client. For this to work properly i feel like the devices need to always be discoverable.
Will an implementation based on Google's Nearby or BT work for my needs ?
Is it possible to detect the presence of a nearby device without it being discoverable ?
As battery life is a concern (need to be able to do this for atleast 8 hours a day) is BLE an option?
You can almost certainly handle 8 hours a day if the phones aren't really used for much else. There are a lot of variables, however.
Many older phones require a different type of scanning using infinite scanner restarts in order to properly report "seeing" a peripheral. This can dramatically decrease battery life.
If the phones are running Marshmallow or later, they have a doze mode which interrupts scanning. This can be circumvented using an AlarmManager, JobService/Dispatcher, or WorkManager. This can dramatically decrease battery life.
If the phones are running Oreo or later, they require a foreground service (persistent notification) in order to prevent the app from being automatically killed by the OS to save battery. The app should also be whitelisted from battery optimization because even with the foreground service, the app will still be killed off by the OS.
Finally, scanning and broadcasting and using location services is pretty expensive battery-wise. If you're attempting to cluster phones and guess their position based upon what other phones are nearby, at some level you'll still need the location data off of the phones to figure out where they're at.
You're much better off just scanning. You could carpet your company property with beacons, where each individual beacon's location is recorded. When the phone "enters a region" (comes within range of a beacon), it should send something to your api reporting which beacon it just found. This will tell you what room/area it's in.
Another less flashy (and potentially less accurate) way to track everything would be via the IP addresses of the wireless access points they're connected to. Use a WorkManager to periodically update an api with some unique ID for the phone and the IP address of the AP. Your IT department should know the locations of each of them. This way you get reasonably good tracking and virtually no battery drain.
I am attempting to connect two Android devices close-range without a 3rd party service to transfer two small json payloads back and forth before closing the connection. Think adding nearby contacts.
I am using the P2P_POINT_TO_POINT Strategy and have both devices advertising and discovering using the code found here: https://developers.google.com/nearby/connections/android/get-started. It consistently works, however it repeatedly takes 10-15 seconds to find the connection and prompt to accept the connection.
Ideally I could get this below 10 seconds.
I read that having one dedicated to advertising another dedicated to discovering helps but it does not work for my use case.
Is there a way to improve the connection rate?
Unfortunately, the best you can do is to try to connect in one direction. That should lower the connection latency to 2~7 seconds. When both devices connect to each other at the same time, that causes thrashing and while we do our best to handle it gracefully, it will cause increased latency.
Stopping discovery before calling request connection would help too, but not by much. We already do it internally during the most sensitive operations.
Our advertising and discovery stack is based off of Bluetooth, and we've experimented with other technologies to compliment it. But they typically have harsher limitations than Bluetooth does (needs a router, needs a very recent Android phone, can't handle simultaneous connections, can't advertise and discover at the same time). Of all the technologies I know of, only mDNS would be faster while still allowing bi-directional connection attempts, and that requires both phones to be connected to the same router (and that the router hasn't disabled mDNS). Typically this means it only works at home. If that's a reasonable limitation for you, then I can pass that on to the team.
I have been doing a ton of research on this project I want to do, probably read every SO post (bluejacking, RFCOMM, beacons, etc...) and my head is spinning.
I want to create a system at home, using Arduino (with bluetooth le) that will scan bluetooth and detect when my phone or any of my family members phones are in proximity. Whether this is a MAC scanner or simply getting the friendly name. I would also like to get the RSSI. I dont need to do accurate distance measurement but I would like to know approximately how close they are. Does anybody have any suggestions for this approach? I know I can create an app on the phone and have it become a beacon and this may be an option but I am concerned with Android, it would have to be Marshmallow 5.0 at a minimum. I would like support to be a little lower than that, like JB or KK. So, it seems like there should be a simple scan, just looking for the MAC or name. That is all I really need.
That said, the main question I have is, can you scan for and see bluetooth devices in range if they are already paired to something? Like a Bluetooth headset? I understand bluetooth is point to point but does it allow multiple connections or at least broadcast the mac or name when paired?
This question, along with any general suggestions will help me out tremendously!
Thanks!
Bluetooth Discovery from the Listener involves Listening for Bluetooth Inquiry packets(RX) and inquiry response (TX).if done continuously this will deplete the battery. Hence most devices (including Mobile Phones and Headsets) has a policy of when to be discover-able and connectable. Headsets in particular are discoverable only when they are instructed and connectable until one device is connected to it ( There are probably exceptions where the headset has the capability to be connected to multiple phones at the same time). Most Mobile Phones are discoverable only when they are in settings screen ( Android,IOS and Windows Phones), but unlike the headset case they are connectable.
so one option with the MobilePhone is to see if it is possible to connect to them after pairing once ( for example by trying a service search on the remote device and see if it returns the service attributes, this internally makes a connection and indirectly ensures the presence of the device).
if you are specific about a mobile phone which is already paired then you might need to establish a higherlayer connection ( such as SPP) with Authentication and encryption. This would force a two way check between devices to see whether they are already paired. other less secure option is to rely on the Phone (Android and IOS phones doesn't generally Allow a higher layer connection without encryption/pairing) and try to establish an SPP connection to the phone.
Another option is to use Bluetooth-LowEnergy. But Note that security in BT was superior to BLE till BTv4.1 and same on BTv4.2.