I want to find the devices in the Wi-Fi using arp.
(It must be arp, not icmp packet)
I found a similar app on the Play Store, and It was sending Arp.
Captured on WireShark (192.168.0.22 is android)
Is there any api or function available?
I don't know where to start.
I would appreciate any link or document that might help.
You can cause an ARP packet to be sent if you attempt to reach an IP, which you can do by many ways. One convenient way is:
InetAddress.getByName("192.168.0.22")?.isReachable(2000)
which will send an ARP followed by a ICMP ping packet to the address you pass in.
Related
I am trying to implement a VPN service on Android. I am provided raw IP packets (TUN interface which works on layer-3) and not sure how I am supposed to send the packets. I know I can parse the IP packets to pull out the transport layer data (TCP or UDP) and then send it, but I was hoping there was a way I can just simply send the whole IP packet.
Initially, I tried using a raw socket (https://man7.org/linux/man-pages/man7/raw.7.html) and send it that way but learned that this was not possible due to permission issues. To open a raw socket you need root permissions and Android applications cannot run as root.
I found a project called LWIP (https://www.nongnu.org/lwip/2_1_x/index.html) which says that it is a TCP/IP stack implementation library, but after reading the documentation, I can't figure out how to do this.
LWIP has their raw APIs (https://www.nongnu.org/lwip/2_1_x/raw_8h.html#a17edd059f34f45a770fe2fa458ecf4dd) which looks promising but I am not sure if this is what I need. Basically, I just need a way to send the raw IP packet and then get the response, and write it back to the TUN interface -- essentially a pass-through proxy.
Any help would be greatly appreciated. Thanks!
You're trying to reinvent the wheel. There are several appropriate encapsulation methods like GRE or IP-in-IP.
Sending a raw IP packet requires the use of an IP protocol number in any case, so your receiver can get the packets after registering that number.
For starters, it might be easier to use UDP encapsulation.
I'm essentially trying to take a stream of UDP packets created on my local network, and get an android phone to receive them whether on that network, or cellular data as if it was on the source's local network.
I don't have tons of network experience so bear with me.. I have spent the last week researching this problem and found bits and pieces of ideas to make it happen, but I have no idea how to implement any of it.
It seems a sort of multicast with PIM sparse mode seems to be the best option. If I can have the packets routed to the rendezvous point and the phones subscribe I should be set. Looked at VPN a bit too, however Android apis would make it an annoyance to the user.
So I guess my questions in a nutshell for anyone will to put me on the right path would be:
1:How do I route local UDP packets to a rendezvous point? A special router and a port forward?
2:How can I make Android subscribe to a rendezvous point
3:Lastly, when the phone is subscribed does it act as if those packets are from its local network? Or is there more required?
Multicast is not a good solution for your problem. Multicast packets do not usually get past routers. This post's answer explains why multicasting is not a good choice.
Instead write your own client/server application using standard sockets (not multicast) where the server streams the data to each client individually.
Can anyone point me to any sample code which explains (even slightly) how to write a simple wifi speedtest program for Android? I have looked everywhere!
Thanks in advance!
-Michael
It's not easy. Let me give you some suggestions but you will need to investigate more.
I'm not sure whether it is possible to access low level metrics of the WiFi connection or a 3G connection. Supposing it's not possible, my suggestions are oriented to use a ping or a ping-similar solution with some server and obtain the round-trip time (RTT).
Now, when you connect to a server, there are many factors affecting the RTT, these are the main ones:
WiFi speed, congestion, and communication errors
Latency in the whole path to the server, including ISP capacity and backbones.
Congestion in the path
Server speed to respond
Usually you execute a ping to test reachability and a taste of RTT. Ping is implemented with ICMP Echo Request. However, Java does not provide the means to send an ICMP message. So you might try to establish a TCP connection to some server.
You could use InetAddress::isReachable with a timeout various times until you find out the limit timeout. I wouldn't recommend this.
http://docs.oracle.com/javase/7/docs/api/java/net/InetAddress.html#isReachable(int)
I would create a TCP socket and call connect and then determine the time it took since connect was called. Of course you have to deal with all factors that affect speed.
Another point to consider is that if you use connect in a TCP socket, you have to understand that there is actually a three-way handshake: client sends a SYNC, server sends SYN/ACK, client sends ACK. But this last ACK doesn't add significant time to the return of connect because it's just sent by the client.
Having said that, I'll go with some suggestions:
First thing I would try, only with a WiFi, is trying to establish a connection to the access point, to port 80, 8080 or 443. That would eliminate other the last three factors.
If it doesn't work you could try a fix server, www.google.com for example. In this case you will have to deal with all the mentioned factors.
In the case of 3G, I don't know how you could could establish a connection to the access point like a Gateway GPRS Support Node in UMTS. But you can connect to a fix server, considering all 4 factors mentioned above.
Other point to consider si that when the smartphone has connectivity to WiFi and Cellular, it always uses WiFi. There are ways to force it to use 3g though, some links:
Android: Force data to be sent over radio vs WiFi
Force Android to use 3G when on local area wifi without net access
I hope this helps.
I have an issue which I can't even start to solve after hours of researching. I need to use GCM to facilitate peer to peer file transfer (JPEG image of circa 1.5 megabytes in file size to be specific).
Client A opens a socket and uses AirBOP to notify client B that it wants to send a picture and gives B relevant information (IP address + port to use, ephemeral I guess). B then connects to A and downloads the picture. All this behind NAT and via 3G/4G if at all possible. No server involved.
I looked into TTorrent, Snark, Cling, NAT hole punching, PWnat etc. but I still don't know how to achieve the above, and if it is possible at all. What i did understand is that i will need to use port mapping or UPNP.
Sorry for poor English, and I'm looking for a road map/guide lines/library/existing tutorials/projects on solving the above problem.
Thank you.
Google Cloud Messaging (GCM) was not designed to deliver large payloads. It's intention was to provide a light-weight messages for your application to then handle the heavy lifting (e.g. a new email notification informing your application it is out-of-date and that it should retrieve the new email). With that said, it does however have the ability to carry a payload of up to 4Kb. Which is obviously not enough to handle your 1.5Mb payload. You might think about implementing some type of protocol that will assemble the complete payload after x number of GCM messages. First, there is a quota on the number of GCM requests allowed per day per ip address. Second, GCM explicitly does not want its service to be used in this way and will block GCM messages if it detects it is being used that way. See http://developer.android.com/google/gcm/adv.html for more information.
What you need to implement a p2p application is either a STUN server or TURN server. A STUN server is used to discover the public IP and port that is being used by the device to communicate with the internet. You can either implement your own STUN server but requires a server that is publicly accessible/routable from both peers or use a public STUN server and use GCM to notify each peer of the others public ip and port. A major limitation with this technique is that if one of the devices is behind a router/NAT that has been configured to use symmetric nating, it will not punch through. There are exceptions to this but generally this is the case. Using a TURN server basically just relays the data from one peer to another peer via a central/public server. This isn't much of a challenge except it will cost you since this type of solutions puts a heavy load onto the server as oppose to a STUN server and you may need to purchase several servers to handle your user load.
I'm in the middle of my own p2p project and what I've discovered is that Verizon implements Port-retricted cone nat, AT&T symmetric cone nat, Sprint symmetric cone nat. Considering the popularity of mobile carriers (Verizon #1, At&t #2, Sprint #3), this is something to consider.
STUN Protocol
https://www.rfc-editor.org/rfc/rfc5389
I'm in the early stages of writing an app that will need to broadcast data to several other devices.
My first thought was using an UDP broadcast, however according to both
http://code.google.com/p/boxeeremote/wiki/AndroidUDP and
Android 3G UDP Broadcast
he UDP will not be able to push through the NAT when on the mobile network
(which is essential for my app).
I know that i could either use a server to broadcast however i'd rather avoid generating to much traffic on my home server.
The last alternative that i can think of is having several tcp/ip connections and looping through all connected clients and sending the broadcast. But since I'm counting on having at least 30 listeners I believe this will be to expensive.
I do not have any broadcast associated code yet, that's why I haven't posted any;)
Is there a way to break through the NAT? Will the phone be able to handle 30 simultaneous tcp/ip connections? Or should i look into some other method of broadcasting?
Any hint would be greatly appreciated!
Kind regards
Johan Risch
:::::::::::::::::::::::::ADDED::::::::::::::::::::::::::::::::
I will be sending strings of length 10-20 characters once every 30-360 seconds
(will be controllable by the user) containing geo points in string format. The order in which the data will be sent is not important, that's why I thought of udp first.
I've set up my server so that when a user logs in he/she updates my database with his/her current ip.
Preferably i'd like it to work globally, but as long as it would work within the mobile networks in the same country.
That's about all the relevant information i can think of, hope this clears some things up!
:::::::::::::::::::::::::/ADDED:::::::::::::::::::::::::::::::::
The NAT doesn't pass UDP through because UDP has no destination address, so technically UDP has to be sent to all subnetworks of the network. When the network is your home LAN, it's no big deal, but when the network is your ISP or university backbone or cellular provider, the UDP could be replicated to hundreds of thousands of subnets. That's a packet storm that will degrade network performance for everyone, and it's massive overkill for your particular app since you really only want to talk to a small number of clients.
This problem has been solved many times already. Instant Messaging clients have a similar situation as yours: want to do direct P2P messaging when possible, through firewalls. How do they do it? The original NAT traversal / firewall traversal solution was to set up a message relay server. All clients talk to the server, and the server echos messages from one client to the others as appropriate. It works with NATs and firewalls because the client initiates the outgoing connection to the server.
If the clients are able to establish a peer to peer connection, then the relay server can just give the clients each other's IP addresses and stop relaying messages.
UPNP is a protocol that enables clients to request a firewall to open a port for incoming traffic. BitTorrent clients use UPNP to enable clients to connect P2P for file sharing. Clients find each other via the torrent server. Most home LAN firewall routers support UPNP now, but it seems doubtful to me that a cellular network provider would provide UPNP support for over the air connections.
Another (remote) possibility is multicast TCP/IP, but as I recall this is really optimized for "push" content flowing from the server to clients rather than client-originated peer to peer.
Your best bet is to take a look at the open source IM clients out there, particularly ones with Android implementations, and see how they're doing IM. Jabber is one that comes to mind, I'm sure there are others. You could even use an IM system's messaging API as your data transport layer and more or less stay out of the wire level details completely.