I am maintaining a small app related to wifi networks. It tests internet connectivity when the phone connected to a wifi network.
While testing and using the app in a place with two neighbouring wifi networks (different SSIDs) with slightly overlapping coverage with a HTC Desire running Android 2.2.2, the sequence of disconnecting and connecting when moving from wifi A to B seems to be:
Disconnect from wifi A
Connect to wifi B
Now with a Fairphone running 4.2.2, the sequence seems to be:
Connect to wifi B
Disconnect from wifi A
Does this mean that unlike the HTC Desire, the Fairphone does some sort of roaming and first connects to the wifi whose signal became stronger than the one of the current wifi connection, and then drops the "old" wifi connection?
I am asking this question because if my observations are correct, this has some implications on the app's behaviour, i.e. it should not consider the last wifi connectivity event but rather check the actual state of wifi connectivity regardless if the last event was "connected" or "disconnected".
On android, as on many linux flavors, wpa_supplicant controls roaming behavior. You could look into it so to see what it is doing.
Specifically to answer your question, it is possible for a WLAN Device (in linux), to use different types of drivers:
SoftMAC: MLME (Media Access Control (MAC) Sublayer Management Entity) is managed in software.
FullMAC: MLME is managed in hardware.
Particularly some of the MLME functions are:
Authenticate
Deauthenticate
Associate
Disassociate
Reassociate
So differences are to be expected in some of this mechanisms on different devices and versions of Android (driver types, wpa_supplicant).
The correct 802.11 behavior for roaming is to send an Reassociation request to the newly selected AP. Clients that first Disassociate from an AP to later Associate with a new AP actually do not support 802.11 roaming and use some sort of fake-roaming through a SoftMac approach.
In standard roaming packets sent to a station do not get lost and are forwarded from one AP to the roamed AP in order for the roaming station to receive them.
Related
Does anyone know of a way to count 802.11 beacons for the network you're already connected to? Doesn't matter if its an Access Point or Adhoc network as both will issue 802.11 beacons.
I'm asking this question from a Linux platform development perspective (Linux and/or Android). I've been working with Adhoc networks and Linux devices, and need a method of determining if the nodes in the network are alive without having to write a heartbeat service. I know that Access Points issue 802.11 beacons regularly for clients to detect them and wondered if an Adhoc network clients had some similarities. (there are Adhoc features relating to ESSID and BSSID that would suggest the clients would have to advertise the Adhoc network)
I've been testing this theory by using Kali Linux and an Alfa Wifi adapter to monitor 802.11 wireless traffic. (not a typical setup, and I only want to count beacons from the connect network) I then setup a 2 node Adhoc network between 2 Linux systems. airodump-ng noted that the clients were generating a lot of frames. I admittedly didn't set an iptables rule to block all outbound TCP/UDP, so the activity could have been some background process trying to get online.
After firing Wireshark up I noticed that some, if not all, of the frames were 802.11 beacons! They were emitted very regularly, like 2-5 beacons per-second.
I don't know if there's some function or configuration that 802.11 Adhoc must be in to issue these beacons or if it can be tuned, but they are there.
A function could be written to count beacons for the connected Adhoc network, and if one of the clients stops sending them, you could assume that communication was down with that client.
I don't think Netfilter will see these frames as it sits higher up in the network stack. e.g. above carrier frames
The problem is I need a method for seeing/counting 802.11 beacons for the network I'm already connected to, without a special wifi adapter or pen testing tools. Any suggestions? Thanks!
The answer is no. Generally if your 802.11 adapter/driver is not in monitor mode (promiscuous mode) beacons will simply not float up through the stack, even for a network already connected to. Monitor mode turns off all filtering. Kind of disappointing that it's all or nothing but that's what it is.
I want to work with Wifi connection via Android Devices (for example I want to send a command with my device to home router via Internet and my router send this command to a wifi module) when I refer to Developer Android APIs, I see a section that named "Wi-Fi Peer-to-Peer". what differences exist between wifi (working android devices with access point like home router) and "Wi-Fi Peer-to-Peer". Is "Wi-Fi Peer-to-Peer" same wifi Direct ? why Google didnt discusses about simple wifi ? please help.
WiFi P2P (Peer-to-Peer) and WiFi Direct are both the same thing.
There are two main differences between "normal" WiFi and WiFi P2P (from the developer's point of view):
A WiFi p2p connection (something you establish from code) is a direct connection between two devices. You can understand it as a sort of temporary (created for the time of the connection) "normal" WiFi network created for the purpose of communicating those two devices. A "normal" WiFi connection basically translates to a situation when a device is connected to a broadcasted (by some device - e.g. home access point, or a smartphone) WiFi network. This all basically means that to send data between two devices using WiFi P2P, those devices DO NOT have to be connected to the same WiFi network (as long as those devices know how to connect to each other using wifi p2p). Unfortunatelly good news with WiFi P2P end right here, because:
Designing a WiFi P2P connection based system is extremely difficult if you want to make it at least reasonably robust. This is mostly due to the lack of documentation on that subject (in Android Dev), and due to Android's WiFi p2p unpredictability (I know what I'm talking about - I was recently desigining such system).
You're wrong saying that Google didn't discuss "simple" WiFi. You just need to remember that connecting to "simple" WiFi is just not that complicated, so they didnt have to do a guide like they did for WiFi P2P. All information considering "normal" WiFi are there (at Android Developer), its just spread over many classes.
Tell me what you think is not discussed?
Also you should try to describe the exact thing your application needs to do (with WiFi), so I can maybe give you a hint whether you should try your luck with WiFi P2P or not.
I have read these Getting Started with WiFi on Android. Implemented Marakana's tutorial for basic wifi functionalities.
But my question is: Is there a way to find the number of users connected to a wifi network?
If it can be done, kindly share a link or resources.
If it cant be done, kindly provide some detail, why not?
Thank you,
Getting a list of computers on a network is inherently an unreliable proposition, wifi or wired.
There are three common approaches: a discovery protocol, scanning, and passive listening.
Discovery protocols (such as LLDP from the UPnP framework) work very well for devices that support them. Occasionally also for devices that don't. They don't work at all if firewalls block them, or if switches or wifi access points are configured not to allow traffic between devices.
Scanning means, sending a probe (such as a ping) to each possible IP address. This is something many intrusion detection devices block, and many wifi access points will also prevent you from sending a ping to another device. Also, scanning is entirely unfeasible in IPv6 because each network has billions of IP addresses to probe, rather than the usual 254 in IPv4.
Passive listening means, simply paying attention to the layer-2 traffic on the network, and building a table of MAC addresses based on the ARP traffic (or all traffic). That only works reliably if you have a wired network with a hub - switches don't forward all layer 2 traffic everywhere (although the ARP messages you need most are usually broadcast and available). WiFi isolation may also prevent you from getting enough layer 2 traffic.
Since I don't have an Android 4.0 device I haven't been able to test this myself. Also I wonder if connecting device A (a smartphone) to device B (a wifi direct capable device) using Wifi direct would mean that device A would assume it is provided with internet from device B (tethering?). I am trying to make an application for device A that would communicate with a device B that does NOT provide internet, thus it would be interesting to know if such a scenario would lead to device A losing internet connectivity for the duration of the connection. Is the situation different depending on if device A is connected to internet through an AP or through 3G/4G?
Perhaps using Bluetooth would be a solution, but in my case security is an issue, and it seems to me that Wifi direct provides stronger security (WPA2).
Any info would be helpful!
/S
On Android, Wi-Fi Direct doesn't interfere with your connection to the Internet (Wi-Fi or 3G/4G). A problem may be that once your turn on the Wi-Fi (to enable Wi-Fi Direct, your phone will try to connect to one of the saved available networks and will disable your 3G connection. That is because Android (by default) doesn't support dual connection (via both Wi-Fi and 3G/4G), but there is some applications around that claim that they can provide such functionality.
Can someone explain a couple of very simple concepts to me - I'm interested in mobile devices running android and how they are identified over networks. Some scenarios:
Device is connected over WiFi - presumably the device has a standard IP address as with any host and can communicate with any other android host over TCP/IP (assuming it knows the participating device's IP?
Device is connected over bluetooth - how are devices identified in this case?
Device is connected over mobile operator's network - this is the one I'm interested in and confused by - is there anyway for two or more devices to discover each other and communicate via the mobile operator's network? How does a device communicate with a backend server in this scenario? In other words, how do apps and devices communicate when not connected to a WiFi network?
Thanks for any advice..
I'm only sure about the bluetooth thing, so i only answer this part:
The Bluetooth interface on your device has an MAC adresse. So while communicationg over Bluetooth you can assume that this MAC adresse is a unique identifier for a specific device. You can also reach other devices by establishing a connection over this MAC adress- However, to get this mac adress in the first place, you have to know it from somwhere, or you have to search for other bluetooth devices in the reachabla area before.
WiFi and 3g both attach the [mobile] device to the internet so it can make internet connections. 3G assigns a publicly addressable IP to the device, so one could, presumably open a server socket and listen for connections. The client would have to know the mobile IP, which may change quite frequently.
Bluetooth is more geared toward close-proximity. Devices in the vicinity can be connected to, after you have paired with them, which requires the cooperation of both devices which are to communicate.
If the goal is to produce an application which connects to nearby devices, I can think of the following ideas:
3g: all devices running the client register their position with a central database server. If the server detects that two clients are in close proximity, let them know so they can connect through the internet or through the server
WiFi: you could use the same idea as 3g, or use broadcast/multicast packets to broadcast your presence. Other apps can listen for those broadcasts and discover which other devices are near.
Bluetooth: A little trickier, as a device must be placed into discoverable mode in order for others to "see it". Discoverable mode is a temporary state and only lasts about 30 seconds (at a time).