This is sort of an odd question, but I know it is possible.
I am trying to broadcast packets over a specific frequency and I want a phone running an application to pick up on these packets. The phone will not need a connection to any network to do this, but simply have it's wifi turned on. The broadcasting device does not need to get any information back from the phone and delivery of every packet to the phone does not need to be guaranteed, much like UDP.
Where do I start? Is this possible for phones without rooting them. Is there some kind of FCC regulation against doing this (over the standard wifi spectrum).
I know this is possible because it's exactly how routers tell a phone they are available to connect. Thanks in advance for any input.
I'm not familiar with iOS development although similar techniques may exist.
Without root
But requires coarse- and/or fine-grained location permission on Android
You can use WifiManager.getScanResults() to scan for wireless router broadcasts.
The network "name" (SSID) and router MAC address (BSSID) are included in the results. You could broadcast these packets and encode data into these fields.
That said, I hope your messages are short as you'll be getting 38 bytes per packet (32 SSID bytes + 6 MAC address bytes).
Yes, some MAC addresses are special or invalid, but if you're just broadcasting and not actually using them, they can still transmit the data.
With root
Depending on the wireless chipset and driver support, you may be able to put the device into "monitor mode" which gives you access to the raw packet data.
The main drawback is that there is no official support for it.
You might find some hacky ways to do this from a Google search but I wasn't able to find any universal solution that works on all (or even most) devices.
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.
My question is that is it possible to send and receive data between multiple android devices via broadcasting over wifi without establishing p2p connection?
Our professor asked us to design a wireless network system in which you broadcast a message within your android phone, and the other android phones nearby receive it and broadcast it again so that the other phones can receive it and it continues like that. In this way, for example, when someone writes a message in a classroom or café everyone will be able to receive it and broadcast it again. (like an adhoc network system). And although my professor believes it can be achievable, I didn't find anything online like this kind of android network system. So my question is again is it possible to do something like that?
Any helpful leads and references will be appreciated.
Edit: I had to change the title of the question.
I couldn't find a proper solution so I tried the following method so far: I set up a UDP messaging app using Wifi hotspot (it works perfectly for multi clients). The phone who turns on the hotspot is the server and others who connect to it are the clients. Then, I decided to turn this system into an adhoc-like system where there would be more than one hotspot and the clients would connect to them in cycling order and serve as a bridge among these servers.(every second, they will switch to other hotspot and vice versa.) So, they will carry the messages from one network to another. (I know it is very inefficient and prone to time delays; but it is the only idea I have come up with so far.)
When I told this system to my professor, he said that it is too complicated and I just need to broadcast a message from a device to a common channel(without setting up a network connection), and other devices will listen to this broadcast channel(without connecting to a network system), receive the message and broadcast their own messages along with received ones to this channel again as I described in the question body. (he never mentions hotspot, Wifi direct, and etc.) He even told me that the only thing I need to do was to think simpler and use the properties of 802.11. But, I do not think it is that easy to set up such a wireless system, at least for Android where ad hoc systems are not supported yet. So any help will be greatly appreciated. Thanks!
The Nearby Connections API in Google Play Services released last week uses WiFi multicast: https://developers.google.com/games/services/android/nearby
It works for devices already on the same WiFi network. However, it uses a host/clients model, and doesn't work with WiFi direct or a tethered hotspot connection.
You could also use the WiFi direct APIs from ICS: https://developer.android.com/guide/topics/connectivity/wifip2p.html
You can have multiple devices connected together via WiFi direct, so firing UDP packets as #willis suggests would seem the way to go
It is implementable. Do you know the aircrack? similarly, you can receive all packets even not sent to you, and you can send any kinds of packets even not sent by you.
I am working on one project in which two android devices which are in different network need to transfer some data. Both device will have internet connection. It will be either Wifi or GSM provider.
Consider the following cases:
If one Android device has GSM network and
another device in some other place which has Wifi network
If one Android device has GSM network and another device has GSM network
How to transfer data in such cases?
I don't want to use server in between.
Please let me know how do I solve this issue. Any clue or any links which will help me. So far I didn't find any such things. Please help me...
Short Answer: You're going to have to use a server.
Long Answer: You could use bluetooth if the location is close enough or maybe Wifi Direct although I haven't personally used the latter. Although, ultimately a server will be the best option. If you don't know a lot about backend development I could recommend parse.com as a good service that makes creating backends very easy and has fairly high usage limits before you have to pay.
Unless a device has been configured with an external IP address, which is very unlikely (impossible?) on a cellular network, there won't be a way to directly contact it from an external device. Even on WiFi, most devices will never have an externally defined address.
If you had administrative control over a directly connected and externally addressed router, you could port-forward traffic to a single device, but that's likely not the solution you're after.
A much easier approach is to use one of the services that let you define a back-end w/o a lot of setup or costs. The most popular one is probably Parse.
is it possible to use an android phone to collect IMEIs or unique Phone IDs of phones within the same cell? Probably there is already some hack to use osmocom ... what I am looking for is an easy to work solution to scan traffic (by counting car drivers phones )
Theoretically yes but practically no.
In a normal GSM network you will expect Mobile identity IMEIsv data fields to be encoded in a message called Identity Response.
This message is sent in a encrypted channel called sdcch/8. You need to decrypt (and find) this exact message in that channel to detect the imei of a given uplink transaction.
To be able to catch an uplink data transaction you need to have a radio receiver that is listening on the uplink frequencies and you're android phone does not do that.
You were looking for an easy to work "solution to scan traffic".
What I suggest you do is try to find a phone that will give you information about the CCCH channel this is unencrypted and can contain Paging Requests with tmsi or imsi information. The tmsi is more anonymous and it gives you some kind of statistic for counting.
The "easiest" way to do this (today) is to use Nokia 3310 and the dct3 gsmtap project. Filter the pcap file using options in tshark.
There may be more accurate ways of counting cars.
Well theoretically yes, but the problem here is that you need to know how the radio interface of your android phone works and have a driver for it before you can do that.
As far as I know there are no such drivers for GNU Radio.
The other problem is that the CPU on your mobile phone is not strong enough to handle the amount of data processing needed to perform such task, it may come a day when you have quad core CPUs with lots of RAM and strong DSP support, but I don't think we are there right now.
I'm asking because I've been facing that issue for weeks.
I need to develop an Android application that can be able to perform an Bluetooth Connection and send data to an Bluetooth Hardware.
Ok, so here's the point:
is it possible to perform a RFCOMM connection to an 'unknown' device?
I mean, is it possible to do this without having any information about the hardware code?
Because i'm only able to modify the AndroidDevice (cellphone) code, for SENDING purposes.
I want to send a byte and make sure it was received, but there's only a sending code.
Could we have some more details? Is the other device accessible by you, as in can the other device know information about the Android device? And what do you mean by a "sending code"?
The Android device can pick up any active Bluetooth device in its range, and know the name and address of those devices. So, if the Android device doesn't know anything about the Bluetooth device it wants to connect to, you can always sort through the list of devices in range, and get its hardware code through that.
See the documentation about Bluetooth, specifically the Finding Devices section:
http://developer.android.com/guide/topics/connectivity/bluetooth.html
I've done a fair amount of Bluetooth work with Android devices and Arduinos, and the Bluetooth library might be a bit of a pain to work with, but it is powerful.
With bluetooth the two devices have a UUID. If you a writing a program that runs on both devices you have them listen for that UUID. When they connect as a client or a server you have a dataInputStream and a dataOutputStream. Then you can push and pull bytes out of those.