When I turn on Android Wifi Hotspot, Others join into my network and get Ip addresses.
How's the mechanism of distributing IP addresses between my phone
and clients ?
So is there any methods(Java, Android) or any files in the Phone
system that I need to config to change My Ipaddress(As a Server
Ipadress) and DHCP IP range ??
Related
I'm looking for an alternative to arp scan. Thus I'm aware of that apps cannot access /proc/net from android 10+, and there are bunch of alternatives in which are already deprecated. Therefore, I'm looking for a reliable/working code to scan all the IP addresses and their MAC address of all the devices that are connected to a particular LAN (WiFi). Preferred in Java.
If I know the mac address wlan0 of an Android device, you can send a text message to this device even if the device is connected to a network other than mine?
No. MAC addresses are only applicable for a local LAN through switches, and cannot be used for addressing or routing by layer 3 routers or outside a local network. However, on an IPv6 enabled network, you can directly use the MAC address using a link-local address, or you may use a direct TCP connection if there is a program listening on the device, and you know the IP address and port.
I am working in an application that requires an Android device to connect to a Wi-Fi network. This Wi-Fi network does not have internet access - it is a Wi-Fi network created by a end-device and used only to communicate with it using TCP sockets. I would like to be able to access the cellular data internet connection on the Android device WHILE communicating with this device over Wi-Fi and I wanted to know if this is possible.
Here is what I know so far:
It is possible to get list of all interfaces available on the device and their corresponding IP addresses via the Android NetworkInterface API.
There is an option in the Developer Settings in Android to keep cellular data interface up even when Wi-Fi is connected.
It is possible to provide the local address for the Socket to bind to when creating a Socket()
With these in mind:
When I am connected to the Wi-Fi network with the SIM card in the device and LTE enabled I am able to get wlan0 interface with a "local" IP address in the format 192.168.x.x and rmnet0 interface with a non-local IP address.
However, depending on the device, I am only ever able to access ONE of them at a time.
For example, on a Pixel 2 XL running Oreo 8.1, LTE Enabled, Cellular Data Always On enabled:
I am unable to communicate over Wi-Fi AT ALL. Any Sockets created with the Wi-Fi local address time out.
On a Galaxy Tab S2 SM-T818W running Nougat 7.1, LTE Enabled, Cellular Data Always On enabled:
I am able to communicate over Wi-Fi but not able access the cellular data interface.
The only way I am able to access the wlan0 interface on the Pixel 2 XL is by calling requestNetwork from Android's ConnectivityManager API and requesting Network with TRANSPORT_WIFI capabilities but this defeats the purpose since now all communication and sockets will be bound only to the Wi-Fi network.
I know that when USB tethering is enabled, it is possible to access devices on the Virtual USB "Ethernet Network" interface which shows up as eth0 with either the wlan0 interface or even the rmnet0 interface by specifying local addresses on the Socket connection calls. It just appears to be a problem with Wi-Fi and cellular data.
I wanted to know if this is an inherent and intended Android limitation or is there a way to access both interfaces at the same time that I am missing.
Appreciate your help. Please let me know if it would be better for me to provide specific code snippets, I wasn't sure since it would make this post quite long.
Best,
I'm coding an app which consist of two pieces. Desktop and android. There is one desktop and several android devices. (don't know the count.) I want to communicate android devices between desktop with TCP. However, android devices doesn't know desktop's lan ip address.
I thouht 2 ways:
1-Desktop app changes the local ip address on start. So android devices know the ip address. (I coded with that ip address)
2-Desktop app always tries to connect ip addresses (192.168.0.1 - 192.168.0.255) to sent desktop's ip address. And when an android device connect to the network accept the connection then know desktop's ip.
But there is some problems in both ways.
On first, you must be administrator to changing lan ip. So run command as admin with java is a problem. Because if I do this, when user start the program, uac always asks for it.
On second, I think there will be performance issues because of app always tries to connect. Exept this, when android device connect and dhcp gives it 192.168.0.5 , but loop is on 192.168.0.150. So android device have to wait for connection.
Is there a better way than these?
Look at this post Network discovery in Java using multicasting
I think this would be the best way to do it.
The server will listen for a broadcast message from client
the client sends a broadcast request asking for server ip
server receives request and replies back with server ip.
You can use the hostname. If the network is properly configured, the host name will point to the correct ip even if it changes
I need to send messages to Android phones through P2P on 3G connection.
Sending and receiving works perfectly on lan ip addresses(on wi-fi) but not on 3g or 2g.
On 3g I send a message but it never appears on the other end of the line.
Can anyone tell me how to make a connection ?
What port to use ?
Thanks,
DataSmith
DataSmith, what you refer to as internal and external IP address is most probably private IP address and public IP addresses. Private IP address are valid only on the lan where the device is located. This is why you can connect to other peers on the LAN.
However, there is no way you can connect alone to peers on other LANs (unless they have a public IP address on their LAN, which most probably is not the case). You need to learn about IP address translation and NAT traversal to achieve this. You can check the Practical JXTA II book available online for reading at Scribd.