Proposal: expose DHCP Info

[emcniece]

@becvert what are your thoughts on making the DHCP information available through this plugin? Should DHCP info be available here, or should it be a separate plugin?

I have a use-case for handling services differently based on the network that a mobile device is connected to. Especially in the case that mobile data is enabled and I can't rely on jmDNS to return accurate results.

I haven't found any other @ionic-native plugins that make this information available, and cordova-plugin-zeroconf already has access to the API methods that make this data available.

Example:

zeroconf.getDhcpInfo(
  function(dhcpInfo){
    console.log('DHCP Info', dhcpInfo);
  },
  function(error){
    console.error('Zeroconf error', error
  }
);

=> "DHCP Info" {
  ipAddr: "192.168.37.151",
  gateway: "192.168.37.1",
  netmask: "255.255.255.0",
  dns1: "10.0.0.2",
  dns2: "0.0.0.0",
  server: "192.168.37.1",
  lease: "3600"
}

Platform references:

• iOS: Netinfo
• Android: DHCPInfo

[becvert]

I'm not against adding this into this plugin.

Although about your use-case, does it mean you want to watch and publish services on your mobile data interface? if yes, does it work at all? is it supported by that network interface?

[emcniece]

No, this is not scanning mobile networks, this is still using Wifi.

I'm experiencing problems with Android 8.0 (Oreo) when connecting to devices in AP mode: JmDNS does not produce reliable results (if any) when mobile data is enabled. At first I thought that it might be a problem with specifying the INetAddress that JmDNS.create() is called on, but after extensive debugging (and forcing JmDNS.create(specificIP)) it seems that this may not even be as high-level as JmDNS.

The Android documentation for Multicast Locking states that locks are discarded both when the app exits and when it closes nicely. One thought was that these locks were persisting past app restarts and thus preventing scan results for networks after they have been changed (maybe the locks get stuck on the context they were originally bound to?), but if the locks really do get deleted on close/crash then this can't be the case.

To test this, I have created a barebones native Android app that uses JmDNS to scan. The results returned by the native app are the same as in the Ionic app for IPv4 networks. When mobile data is enabled, the app doesn't find any scan results - and when mobile data is disabled, it finds results more often. I'm avoiding IPv6 for now.

I am testing this behaviour on 3 Android 8.0.0 devices: Google Pixel, Nexus 5x, and a OnePlus One (LineageOS). The only device that scans reliably is the OP One - the other two require a troubleshooting process to get results to show up reliably:

1. Change Wifi networks
2. Force-close the app
3. Disable mobile data if enabled
4. Forget the network if it is saved
5. Re-open the app

This case is specific to connecting to a hardware device which broadcasts an AP WiFi network. The hardware device creates the AP, and it also broadcasts its own Bonjour service (using C++/Avahi). The two problematic mobile devices (Pixel & Nexus) can find peers on this network more often than they can find the AP-providing device service, but all discoveries are intermittent.

I am considering a scenario where the app can detect the gateway assigned by the DHCP master and test some IPs for services without using mDNS. When the app connects to one of these hardware APs, the DHCP gateway is always 192.168.37.1 so if the app can see this then it can guess that there is a service at that IP and try connecting.

This use-case is a failure scenario when zeroconf doesn't return results. Adding the DHCP information is a nice-to-have, not imperative to the functionality of this plugin... hence my question about whether it is a good idea to add this data to this plugin.

The DHCP data could very well be its own WifiInfo plugin, and it would be quite minimal. Need to think about this more.

[becvert]

Thanks for the explanation.

If you do a WifiInfo plugin we could maybe move the getHostname method in there and even the getInterfaces method from my websocket-server plugin.

[emcniece]

It sounds like a WifiInfo plugin is a good idea. I'll start writing this today.

[emcniece]

https://github.com/emcniece/cordova-plugin-wifiinfo