My question is whether port knocking can help me in the situation stated in this question (socket connection issue between 2 carriers' network) to allow connections between an android server and android client?
Depending on the carriers, you may be able to. Verizon (in the US) sometimes uses NAT when they run out of IPs. If the Verizon device is a mifi you could wind up with double-NATed routes, but even simple NAT requires the use of UPNP (not generally supported by the routers they use), or an external server to penetrate the network, such as SIP or STUN.
Related
I am writing a p2p messaging Android app, and I'm trying to solve the problem of NAT on mobile networks. I cannot currently find a way for a device to connect to another listening device on a 3G/4G network due to the carrier's NAT service.
I have heard of a few NAT punch-through methods, but a lot of those involve using some sort of centralized server as a mediator. I am trying to use a completely decentralized p2p approach to accomplish this task.
Are there any feasible ways of allowing a device on a mobile network to be publicly addressable?
Thanks!
No, it is not possible. Most of the time, subscribers with IP addresses NATed are behind NAT444 and many subscribers are anycasted ( subscribers have the same IP on their mobile phone, but nated behind a different NAT devices). And 2 anycasted suscribers cannot communicate together.
The only way left you is to open a VPN to get a real IP of Internet Public.
My suggestion would be: Do not use VPN for IPv4 ! Use VPN to get a real IPV6 to your mobile phone application, and build your p2p application over IPv6.
You are fighting with very old problem that drove IETF to build IPv6.
So, go to IPv6, and forget ipv4.
The ONLY good solution for your problem is to build your app over IPv6, and your app has to bring the ipv6 tunnel to the phone.
I have two Android KitKat phones, both are running WiFi-Direct groups as Group Owners, let's call them GO1 and GO2
I managed to connect GO1 as a legacy client to GO2 without breaking any of the (previously set) wifi-direct groups.
The problem is that, as you might know, the GO IP address is hardcoded in Android source, and is set to 192.168.49.1
Therefore, both of my devices, GO1 and GO2 have the same IP address (**)... each on his local network.
My app is both client and server at the same time. But both networks are using the same IP range (192.168.49.XXX), which, apparently, I cannot change.
As a result I cannot create a TCP connection between them if they are both hosting a WiFi-Direct Group, since any device will connect to itself when trying to connect to 192.168.49.1
So the questions are:
Is there a way to change the IP range used in Wifi-Direct?
Is there a way to use IPv6 instead of IPv4 in Wifi-Direct?
Can any of this be done without rooting the phone?
Any other suggestion?
** : Actually, because GO1 is connecting as a legacy client to GO2, then GO1 is known as 192.168.49.227 (for example) to GO2 and GO2 is known as 192.168.49.1 to GO1. But because GO1 is ALSO a GO, it also known as 192.168.49.1 to his clients (and itself).
A way to get around this without rooting the phone is to send your packets via multicast UDP*. These packets will make it from GO1 to GO2.
There are some side effects to this:
To use this for networking you must perform encapsulation and routing at the OSI Application level (not efficient).
You will also need to route based on MAC addresses since every device has the same 192.168.49.1 address.
"It is important to note that the multicast socket encapsulates a one-to-many unicast communication and, as a result of this, cannot fully utilize the total available WiFi and WiFi Direct bandwidth" *
Something else worth noting:
As you scale up the number of GOs, you will run into a problem of all nodes operating on the same wifi channel. This isn't a problem with a few devices, but with hundreds of devices, it will be a huge problem.
*This method was mentioned in Colin Funai, Cristiano Tapparello, and Wendi Heinzelman paper titled "Supporting Multi-hop Device-to-Device Networks Through WiFi Direct Multi-group Networking" found here: https://arxiv.org/pdf/1601.00028.pdf
There is no way to change the IP range because as you have correctly pointed out, it is hardcoded in the Android Wi-Fi Direct system service. Personally, I am not aware of IPv6 being enabled on the Wi-Fi P2P interface, and even if it was, it would likely be a hardcoded IPv6 address.
If GO1 and GO2, must be connected to each other whilst both in GO mode, then perhaps look at using Bluetooth or some other transport to allow them to communicate. If communication between GO1 and GO2 can be delayed, then cache whatever information is to be exchanged, and send it between these two devices when one can be the client of the other, e.g. when GO1 can stop being a GO and can be a client of GO2.
I'm just confused about how SIP works but mine doesn't.
I made a simple android server which open up a server socket and listen to incoming connection on 3G/4G network. Then I made a client that connect to the server, the connection was blocked by my carrier's firewall(AT&T).
After this, I downloaded an open source VOIP app based on SIP, and register these 2 phones on SIP proxy, let them call each other, this works perfectly.
I'm just so confused about how SIP works on cellular network, SIP is a p2p protocol, SIP proxy is just for redirecting. How does these 2 phones connect to each other in VOIP session? Why is this connection not blocked by carrier? Can someone explain to me? Thank you in advance!
update: I just tried sending a UDP packet between AT&T and SPRINT network, it does not work ;(
In basic SIP the endpoints media traffic generally communicate directly between each other in a P2P fashion like you said. They do this be giving each others address/port in the SIP SDP negotiation.
In a "perfect" network world this works fine as all endpoints can talk directly between each other.
As we know, this is not the case.
In most cases, the main barrier in the IPv4 world is NAT.
The first solution people came up with is STUN. STUN will give you your "public" IP address that you are using from behind a NAT and the SIP stack will use that IP address in the SIP/SDP packets. This works as long as hole punching works.
The next solution people came up with is TURN. TURN is a UDP proxy and allows a client (e.g. a SIP client) to allocate and use a IP address/port on a private network from a public network (i.e. the internet). It should work in all cases but can put a lot of network overhead on the TURN server. It will not be as efficient as P2P connections tho. The upside of using TURN is that not both sides need to support it for it to work. So it's good when you are talking between a softphone on the internet to a hardware SIP device on a internal network.
The next solution people came up with is ICE. ICE needs to be supported on both SIP endpoints. It works by extending the SDP protocol to allow it to add all possible connections in the SDP negotiation (all local network adapters, public addresses provided by STUN and TURN allocated addresses in priority order). Then one side goes through the listed connections and tries to make a connection. This allows both connections to be "try" to connect P2P and fallback to a TURN connection if nothing else works. It should also work in any networked environment to any networked environment and find the most efficient network path between the SIP endpoints. The downside of ICE is that both SIP endpoints need to support ICE for it to work. (As a aside, ICE/TURN/STUN is now a requirement for the WEBRTC protocol for web browsers to talk between each other for the same reason)
Other possible solutions would be for you to have some sort of "smart" sip proxy in the middle that maybe fakes ICE on one side if the other side doesn't support it. Another is to have some sort of media gateway or B2BUA if transcoding is required, this would have the same problems as TURN tho.
I would suggest that you setup your SIP client with STUN, TURN and ICE if possible and that will increase the likelihood of the SIP call actually working.
As to why your case doesn't work now, it would require network and/or SIP logs to understand what the exact impediment is.
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 am implementing a mobile chat application, I am using socket connection for implementing p2p connectivity. My chat is working fine with android devices. My issue is I can connect a device in 3g network or with in the same WiFi network but the connection is not working when a device form outside WiFi try to connect a device in the WiFi network. I know it's because of the local IP of the device assigned by the WiFi. How can I root and connect a device in the WiFi?
Sounds more like a router settings issue, than an app issue (meaning that users of your app would need to do this for their own networks as well).
Your wifi router needs to know how to forward communication to your device. So say that your app is connecting on port 1234, then you need to tell your router to forward communication from the outside on port 1234 to the internal IP of your phone in your wifi network.
The phone that is outside of the network should target your network's external IP and port 1234.
Sajan, your issue is not only an IP mapping issue, but also a NAT traversal issue. It is not always possible to punch holes in NATs. And when it is, it must be done with some sophisticated techniques including a super peer located outside of your wifi/lan which will read the translated address from your inside peer.
Unless you are using UDP and the NAT is friendly, it is not possible to send TCP communication directly to the inside peer. In most case, you'll have to check what is possible with the NAT, and if there is something possible, you'll need to perform mapping prediction and tell both peer to attempt com on predicted IP addresses.
That's valid if you don't want you users to have to configure their NATs. And even in that case, such configuration will not always be enough (if there are cascades of NATs, or proxies for example).