Is there any way to set the dns for mobile network on android?
I've searched everywhere and only found how to set dns for wifi using wifimanager.
It may not be what you are referring to, but just in case - in a mobile network there is a DNS that is entirely separate from the public internet DNS.
Its purpose is to provide domain name resolution within the mobile networks - for GPRS roaming, networking between different operators IMS system, delivery MMS between operators etc.
Its kept completely separate, largely for security reasons, and the network operator or the GRX/IPX operator sets the DNS - IP Packet exchange (IPX) is a network connecting IP network providers and GPRS Roaming exchange (GRX) is a hub for exchanging traffic between GPRS providers.
The mobile or 3GPP DNS is not set by the mobile device or by an app on the mobile device (unless the app happens to be admin app for a member of the GRX/IPX operator team...).
As a simple example, to try to show how this DNS is actually used, an SGSN node in an operators core IP network may want to get the IP address of a GGSN node in the network that it needs to communicate with - it uses this mobile network DNS system to resolve the domain name of the GGSN. Its fairly clear why you would not want a mobile device to be able to influence this process - otherwise a rogue mobile device could change how the elements of the core network communicate with each other.
Related
I am building an IoT solution where I will have multiple devices connected to my local network that I want to connect to a hub that controls my solution.
Once I connect a new device I want to connect it with the hub and give it a name to identify it. I would like to implement the detection in an automatic way (so I don´t have to enter IP addresses manually). As an example when a Chromecast is present in a network I can see it in my streaming applications in my phone. So I want to do something similar to connect the hub with the devices.
My ideas so far is that it is two ways of doing this:
The hub scans the network for new devices (either periodically or when I say there is a new device present).
The devices scan the network to find the hub once connected.
Is any of these approaches to prefer over the other and in that case why?
When doing a scan, in whatever direction I choose, what is the most effective way to do the scan? I am doing an implementation using Java and what I have so far is this:
int timeout = 100;
for (int i = 1; i < 255; i++)
{
String host = subnet + "." + i;
if (InetAddress.getByName(host).isReachable(timeout))
{
String hostname = InetAddress.getByName(host).getHostName();
String canonicalHostName = InetAddress.getByName(host).getCanonicalHostName();
System.out.println(host + " is reachable. Hostname: " + hostname + ", CanonicalHostName: " + canonicalHostName);
}
}
What I have seen here is that the hostname returned is for most stuff in my network just the IP address, and not the name that I see as the hostname in my router. I thought I could use the hostname as an identifyer to detect specific devices and understand what they where - but with this small poc that does not seem to work. So how can I identify the devices in a good way?
Is there any library/solution for Java (or Javascript) and ESP8266 to do this already? (Feels like a common problem if implementing "smart home" devices).
There is no single way that we discover devices on a local area network.
Rather than scanning a network, devices generally either use a multicast or broadcast protocol to announce their presence, or they rendezvous at a (usually external) preconfigured server.
Some devices use mDNS - based loosely on the DNS protocol, they multicast packets to advertise their presence on the network. Apple uses mDNS in their products. It's poorly supported on Android, and requires additional software on Windows. mDNS names are normally in the .local domain.
Some devices use UPNP and SSDP - Belkin's Wemo line of products does this. UPNP and SSDP are overly complicated protocols based on XML and SOAP, which are poor choices for devices with limited RAM and processing power like the ESP8266 and ESP32.
Some devices just roll their own protocol. Haiku's "Big Ass Fan" line does this - they broadcast UDP packets with a homegrown protocol that at least initially was vulnerable to a variety of problems. I don't recommend going this route unless you really know what you're doing. Other, established protocols have already had a chance to have the bugs ironed out. Unless you're experienced in protocol design you're more likely to reinvent problems other protocols have had than a wonderful shiny new discoverability protocol.
These kinds of devices will either periodically broadcast or multicast a packet announcing themselves, or the thing you're calling a "hub" would broadcast or multicast a request and the devices would respond to that request.
Not all devices present an interface for direct control over the LAN they're connected to. Some simply rendezvous with a remote server. In this case you discover them by asking the server to enumerate them, and you control them via that server. Google's Nest products work this way - initial provisioning is done via Bluetooth; after that apps communicate with the devices through remote servers.
Devices rendezvousing in this manner are generally preconfigured with the name of the rendezvous server, but they might also be configured with the name of the server during network provisioning (generally an app communicates with them to share wifi credentials; it might also share information about a rendezvous server as well).
We generally do not scan for names in IP address blocks or actively probe for new devices unless we're debugging a network or doing some kind of security sweep.
The process of scanning an IP address block that you described is problematic and unreliable. The only reason it works is that some routers pick up a device's name from the device's DHCP request (or the router may be configured to know the device's name). The router also handles DNS for the devices on the network, generally by forwarding them to the ISP's DNS servers or to DNS servers that the network's owner configured it to use. It intercepts DNS requests for devices whose names it knows and replies to them itself, instead of forwarding them to an external DNS server.
You also have to know about the network configuration to do this properly. Is the network only a /24? What if it's /22? or /16? Are you prepared to scan 2^24 IP addresses if the network is configured as a /8?
Though the router may intercept requests for names and return addresses, it won't necessarily intercept names for addresses and return names.
Scanning also generates an unnecessary network traffic. While your one "hub" scanning may not seem like much, if you have multiple scanners from different makers running it doesn't scale well.
If your "hub" bypasses the router for DNS requests then it also will not be able to resolve names provided by the router.
Also not all routers do this. It's not part of the Internet architecture, it's a convenience feature that some routers provide. You cannot depend on it working.
You could also attempt an active scan of the network, trying to communicate with each IP address on it. We do this for network debugging, but running this continually to detect new devices would be a hostile way to interact with the network.
Network infrastructure devices - switches and routers - of course maintain lists of all active devices on the network. You can access these lists using SNMP (Simple Network Management Protocol), but few consumer switches and routers support SNMP. And allowing access to your network infrastructure to a random piece of software is a network security nightmare.
Your best bet is a simple multicast/broadcast protocol like mDNS. Don't scan, announce or request. It's responsive, doesn't place a burden on the network, doesn't depend on peculiarities of routers, and won't make network administrators hate you.
Long time ago I implemented a similar solution to discover clients connecting to the network. My strategy consisted in taking advantage of the DHCP configuration.
If your devices must ask IP addresses from a Linux/Unix DHCP server under your control, you could configure it to let you know when a device connects or disconnects from the network.
We were using Linux DHCP server, and in the dhcpd.conf there is a section about events. Basically it says that when the DHCP commits to a particular IP address lease for a client it raises an event, and when that happens, it can run a listener you could have defined for that event. In the listener we can ask the DHCP to execute a command, e.g. write the client information (e.g. MAC address) and its IP address lease to a named pipe, and your Java application could just be reading from this queue. (See also dhcp-eval for further details). A similar event can be run when a client releases an IP lease or when a lease expires.
Here's an example
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.2;
on commit {
set clip = binary-to-ascii(10, 8, ".", leased-address);
set clhw = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/usr/local/sbin/dhcpevent", "commit", clip, clhw, host-decl-name);
}
...
If you can control your DHCP config there is so much you can extract from it.
I have an ESP8266 that connects to my WiFi network after being configured (via WiFi Manager library) and runs a HTTP web server that displays certain sensor data. It connects to my specific network with a 192.168.0.XX IP and it works well.
My problem comes with the android app, and how to actually programmatically retrieve the IP that the webserver is running on? My routers DHCP only reserves IP's for a week - so hardcoding the IP into the app is not a good option, and having less tech-savvy people find the IP and configure it themselves is also not what I'm looking to do.
I also can't hardcode a static IP as friends & family will be using this with different networks and routers (so 192.168.0.X would not work on a router with an IP of 10.0.0.1 for example).
So, how do I go about programmatically getting the IP of my ESP8266 that is connected to my local network?
There is a solution that maybe isn't very optimal and professional, but will do for hobby project. You can make your android app scan your local network using http GET on all addresses - e.g. trying to GET something like this: http://192.168.0.X/sensor_status. You can configure your esp8266 device to respond with code 200 (OK) and save this address in your android app's persistent storage. Next time you can simply check if there is ip saved in persistent storage and try to connect to it. If esp8266 is not available under remembered ip, you can re-scan your network.
###Reference:
Android 4.0 has an API to build VPN services.
VPNService (Android Docs)
VPNService.Builder (Android Docs)
Arne Schawbe's Implementation of OpenVPN for Android (github)
One such app with a VPN service is NetMotion Mobility® (Google Play)
Beginning with the "Lollipop" version, Android come with a new VPN type which provides information about VPN connection state, whether requests go over the VPN, etc.
###Test Results
(Connected to VPN)
Android < =5.0(Android Lollipop)
Connection is successful with WIFI(Wlan) and Cellular(rmnet) interface IP’s.
Connection is successful with VPN(tun) interface IP address but does not get VPN connected/disconnected events.
Android > 5.0(Android Lollipop 5.1 and 6.0)
Connection is not Successful with WIFI(Wlan) and Cellular(rmnet) interface IP’s.
Connection is successful with VPN(tun) interface IP’s address and also get VPN connected/disconnected events.
tun interface IP:
ConnectivityManager#TYPE_VPN
NetworkCapabilites#TRANSPORT_VPN
NetworkCapabilities#NET_CAPABILITY_NOT_VPN
Indicates that this network is not a VPN. This capability is set by
default and should be explicitly cleared for VPN networks. Constant
Value: 15 (0x0000000f)
###Questions:
When the VPN service is active on the device how do requests work from 3rd party apps like WhatsApp, Skype or the browser?
When the VPN is connected what exactly happens to the device IP stack?
How does VPN tunneling work in Android?
What is the design for an app which binds to active IP and sends requests?
Are the VPN APIs in lollipop (5.0) not stable?
If bindProcessToNetwork is done over Celluar network and WiFi is connected in device, which network will the VPN use?
Will try to answer few questions:
1. VPN doesn't affect other app flows - it just "virtually" place your device in another network. For example some company private network. This mean that all requests being send over VPN connection will go to that network and all rules/filters that applied inside that network applies to traffic generated by phone - which can cause issues to third party apps.
2. Real IP address when traffic go through VPN connection is replaced with VPN's IP addresses assigned by VPN server. Web servers that you connect with won't see your real IP address; they'll see the IP of VPN network gateway that you connect through.
5. With Android 5.0 Lollipop, VPN clients can finally offer granular control over which apps communicate over a secured network, and which apps connect to the Internet directly. Maybe this cause problems.
For VPN API's usage you could check this project : OpenVPN for Android
I am working on design of a device that are installed on clients networks. Currently there is about 180 devices installed arround the world. One major concern is to access them for debugging purpose later.
Context :
All devices work the same.
OS is Linux
Default mode is DHCP but sometimes Static IP
Currently the method to get addresses is :
Log on a computer of the client with any remote desktop software available and search with :
DHCP address in router's leases table (most of the time clients doesn't know their credentials)
Angry IP scanner, scan for port 22 (slow)
ping the name of the device (doesn't always work)
Expecting :
Actually I know it is possible to communicate with devices on network without knowing its IP address by broadcasting on the network but not found any example yet or start point. I would like to write a small Java program that will be able to broadcast on a network to :
List every devices with their IP
Assign IP address to device and/or other functions
Remember : I would like to find devices that have no keyboard, screen or other UI. If I receive a unit from a client (for debug purposes) that was configurated for example with 10.1.1.100 and my computer is on 192.168.1.110 (on the same switch), I want to be able first to know the IP address of this device, second, be able to send a SET IP command (I'll manage how to handle it once I'm able to send data).
For the server part of the device, I don't mind, it could be done in C++ or script... This will probably needed to answer to broadcast and receive requests.
So far, I've been able to create a small UDP client and server.
Client in Java using DatagramSocket, server in C using recvfrom().
The problem with this solution is that my computer need to have the same network mask as the device, example :
Device has 192.168.2.217
Computer has 192.168.1.110
My computer will need 255.255.0.0 as netmask, ortherwise I will not be able to broadcast 192.168.255.255.
Seaching more, the need to change the local computer netmask to meed broadcasting range seems to be a limitation of Java...
new DatagramPacket(sendData, sendData.length, InetAddress.getByName("255.255.255.255"), PORT); // not working
new DatagramPacket(sendData, sendData.length, InetAddress.getByName("192.168.255.255"), PORT); // working only if netmask is 255.255.0.0
I think I will need to go deeper in network protocols to do it the way I want and that I know it is possible.
I have two android devices - one is a server, second is a client. I run WiFi hotspot on server (using some external app, like QuickSettings), and then connect to this hotspot on second device. I have an application which transfers some data between these devices, so I need to get an IP address of the server to be able to create a socket on client. So my question is how can I do that inside my application (not justing by typing the proper IP manually)?
Did you try assuming the hotspot is the first IP in the valid range?
I mean: The hotspot gives you device an IP and a mask (and it should give even a gateway). The IP of the hotspot is the IP gateway, but if the hostspot did not tell your device such IP, the gateway is usually the first IP in the range allowed by the mask.