i don't know if it's the right community to ask (i think so, by the way) so excuse me in advance if this is off topic.
I was thinking about a project in android that involves knowing how many devices are in the surroundings.
Is there a way to "discover" it? My idea is something like this:
my device sends some sort of broadcast ping via ARP (or some Data Link protocol)
Every device answers to that ping
My device counts how many response pings are and this is how many surrounding devices are.
I'm saying ARP or some Data Link Protocol because it should be "beyond wifi connection", knowing not "how many devices are connected to my network" but "how many devices surround me"
Thank you in advance!
IPv4 ARP requests are broadcasts, but they contain the specific IPv4 address of the host for which you are requesting the layer-2 address. All hosts on the layer-2 domain will receive the ARP request, but only the host with the specific IP address will respond to the ARP request.
There are many ways in which LAN discovery tools work, but none of the methods are foolproof because the network protocols were not built with LAN discovery in mind. Also, there are ways in which to configure some LAN devices so that it is difficult to impossible for the hosts to be discovered, e.g. private VLANs, where hosts on the private VLAN cannot communicate with any other host on the same VLAN, except for the gateway.
Related
I'm trying to write an Android app to accept TCP connections from the Internet. Sounds simple but despite weeks of head-banging, I've found no solution and now believe it impossible. I would love to have someone tell me I'm wrong.
I was encouraged by the "ServerSocket()" API function. I was able to create a listening socket (e.g. on port 2000) and connect to it from another app within my device. Unfortunately I find it is bound to (unrouteable) local address 10.0.0.150 which, of course, cannot be seen from the Internet.
I was also able to successfully connect by pointing my device to my local WIFI router and using the router's "Port Forwarding" feature to relay incoming connections to MyPublicIp:2000 to 10.0.0.150:2000. But this is not usable in the field (over an LTE connection) where I have no router.
I've searched StackOverflow and other sites but found no good answer (but plenty of inapplicable or obtuse ones).
From my reading, I hear that most (all?) carriers do not allow incoming connections to be routed to user devices, which may explain my dilemma.
PLEASE: Someone tell me I'm wrong.
I think it is possible.
Looking information about my mobile operator (mobile provider): it can provide a static IP address and my mobile device is available for incoming sessions, but only need to pay for this service.
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.
I want to know about all the device that are connected to the dhcp server.
I have the IP of the device it may be a android phone or printer but I think dhcp is having the information of this devices.
I got something like the "vendor information " in the dhcp protocol stack.
My doubt is I have to identify at least a android phone is on the network ,
Is it possible by this.or how to Identify a android phone is one the network.I have the IP of the android also but I am not getting any information from any way.
I got something like nmap but this tool is not giving a perticular details of the phone.The information provided by the nmap is confusing I am not able to identify whether it is a phone or a linux system as both the system having linux as the os.
Then i got this dhcp -vendor information : but I don't have any idea about how to read these data..
kindly give any suggestion.....Needed for my project.
Thanks
The problem you will have is that modern day switches will stop you sniffing traffic destined for specific MAC addresses so if its hard-wired then you are going to run into trouble. If on the other-hand its a unsecured WiFi connection, or a network with hubs (rare now!) rather than switches then you may have a chance.
You'd need to switch the ethernet controller into promiscuous mode and listen for the DHCP REQUEST and DHCP OFFER commands, inspect the contents and see whats going on.
Another method would be to listen for ARP and RARP requests on the network and use a hardware lookup table for the MAC id to determine who makes the chip-sets, its not going to give you awesome accuracy since a lot of chips are re-used on different devices but it may give you a little bit more info.
In terms of the DHCPd server, unless you have access to that physical machine I'm afraid your probably out of luck, DHCP is a designed as a offering protocol, not a querying protocol.
I am trying to make an application which can connect from a mobile to a wifi controller. Planning to do a socket connection(multicast) ... The only values that i am able to get through the wifi android apis are SSID and BSSID.. Can anyone tell me if i am supposed to proceed with these values or am i supposed to connect with an IP address ? If i am supposed to connect with BSSID.. how do i go about it?
Wifi access points need not have an IP address, any more than wired switches and hubs do. However a large number do, as they also act on the IP layer as DHCP servers and network gateways.
What exactly are you trying to do? It sounds likely that it is not the Wifi access point proper that you need to talk to.
If it supports TCP and UDP, it will of course have an IP address. This will not be directly discoverable from the Wifi APIs, and you'll need some other means of discovering that. It's hard to say what exactly will be a reasonable method to do this without knowing what the AP is, and what services it provides.
Common ways of enumerating services provided on a network include DHCP; multicast DNS/DNS service discovery which is used by "Bonjour" and "Zeroconf"), SSDP and uPnP, and of course static configuration.
I'm not familiar enough with the Android network APIs to recommend anything, though http://jmdns.sourceforge.net/ appears to be a usable Java multicast DNS library.
We want to establish TCP/IP connection between two android devices.
For now we thought that it would be simpler if we make the connection device to device. So there is no server that is between the two phones.
Most of the time (if not always) one has no real IP address (NAT and so on). Is this a problem for creating a TCP socket?
I didn't manage to find any exact information for this. Any advice and opinion will be highly appreciated.
Thanks
Is this a problem for creating a TCP
socket?
Answer is no, it does not make it impossible (unless NAT's have an unpredictable way of mapping IP addresses). However, it is not simple to accomplish.
The short answer is you'll always need a server-like peer with a public IP address to facilitate initial communication between peers located behind NATs. The peers connect to it. A tells server it wants to TCP connect with B. Server notifies B. NAT behavior analysis is performed and if possible, A and B attempt to open TCP communications with each other by predicting the next mapping of the other NAT. If all goes fine (and usually it does) A touches base with B or vice-versa. They close the other connection attempts and communicate with the operational TCP connection. This technique is called STUN for TCP.
Now, there are more complicated reason why things can go wrong. If you want to know more, I have written a book called Practical JXTA II which available for reading online at Scribd. There is a chapter dedicated to NAT traversal.
Hope this helps.
One device behind a NAT is not a problem. The requirement is: the server must be reachable by the client.
I'm using Apache Mina to handle TCP connections. It have really made my life easier. It can be used on both client and server. Give it a try...
Well to make a TCP socket one device must be listening and the other connecting. However in a real world scenario what you describe is sort of hard.
Like if you are going to communicate over a cell network between two phones, I wouldn't be surprised if the network did not allow inbound connections to a phone like that and just sandboxed each phone's IP. So while two phones might be on the same subnet IP range, they might not be on the same physical network which just makes the whole routing problem almost impossible.
If you are in control of the network and are using Wifi and natting the IPs yourself with both devices within your network, you should be able to do this just like any other client server TCP socket.
If both nodes does't have global IPs,, and are not physically in the same network,, then its impossible to communicate over TCP without a server, unless you created a controlling server that act as a relay to tell the nodes about any changes occurring on the other side
It is possible but you can experience some problems.
First of all you have to know the public address of the host you want to contact, and if your two host are in different NATTED networks you should do it using some server (like you do in SIP telephony).
Then you have to hope that the contacted host is behind a 'good' NAT like 'full cone' or similar and not behind a 'bad' NAT like 'symmetric' that not allow incoming connection. The fact you use a TCP connection instead of UDP datagram can help you because of the three-way-handshake. In fact most NAT routers accept incoming TCP connection, but not incoming UDP packets.