I am using bacnet4j library to discover Remote BACnet devices. In the same network, everything is working as expected. But I could not find the BACnet controller device located in the different network.
String hostAddress="10.8.102.28";
IpNetwork network = new IpNetworkBuilder().withPort(47808).withSubnet(hostAddress, 24).build();
Transport transport = new DefaultTransport(network);
LocalDevice localDevice = new LocalDevice(Integer.decode(this.settings.getDeviceId()), transport);
localDevice.initialize();
//Finding remote device
int remoteId=1234;
RemoteDeviceFuture remoteFuture = RemoteDeviceFinder.findDevice(localDevice, remoteId);
RemoteDevice remoteDevice = null;
try {
remoteDevice = remoteFuture.get(); //remote device is null here
} catch (Exception e) {
LOGGER.error("Remote device with id " + remoteId + " does NOT exist!");
}
The above code snippet finds remote device with a given remoteId in the same network. But it can not find a device located in different network. Is there anything wrong here?
That is actually by design. The discovery process takes place using broadcast "Who-Is" messages that are not routed via IP routers. So any devices on a different IP subnet are not discovered this way. If you know the IP address of the remote device, you may be able to configure/program the IP directly as a static IP address.
However, there is something called a BBMD (BACnet Broadcast Management Device). One of these needs to be placed on each subnet, each configured with the IP address of the other BBMD. The BBMDs will intercept the BACnet related broadcasts on its subnet, send it across to the peer BBMD on the other subnet, which will retransmit the broadcast, effectively bridging the two (or more) subnets.
OR, your could configure/program your client as a "Foreign Device", have it register with a BBMD on the far subnet, which will achieve much the same.
BBMDs are fairly common. Most (all) BACnet/IP to BACnet MS/TP routers have the functionality. A lot of BACnet devices also allow the functionality to be enabled.
Hope this helps. See http://www.bacnetwiki.com for more.
UDP/IP Broadcasts - that are used as part of the 'Who-Is' (BACnet) service, generally are not routed by default and in most cases will not be allowed to be routed - e.g. security concerns been the main reason.
But if routing is in place, you could send unicast/directed traffic to the device in question.
(If I remember correctly, theoretically you should now be able to now send a Who-Is as a unicast/directed request - but even if I'm correct in saying that, it's highly likely that the majority of devices will only be listening for Who-Is services via broadcasts only.)
BBMD's are not strictly necessary - and have been considered as security concern as they can give out too much info.
It can be possible to use (effectively) bog-standard network routing instead of a BBMD - having traffic fly across a few different/target VLANs.
(Also be aware of mixing the use of a private IP(v4) address - of your choosing, and a public IP(v4) address - between the client & server/serving-device, you might encounter issues.)
Related
I am working with JMDNS 3.5.4. My PC as well as other PCs are in multiple networks. I was wondering how to define the host-address (IP-address) which is broadcasted within the service.
I tried to select an address using "InetAddress.getAllByName(host)" and use this address in the create function. However, this address is simply ignored in the ServiceInfo object.
JmDNS jmdns = JmDNS.create(INETADDRESS);
// Register a service
ServiceInfo serviceInfo = ServiceInfo.create("_http._tcp.local.", "example", 1234, "path=index.html");
jmdns.registerService(serviceInfo);
Later, the clients which find the service will use its port and IP-address to call a REST-service.
It seems like the DNS cache was the problem - I deleted it.
I will evaluate my suspicion and update this post...
I need to detect the local IP address and subnet mask on the WiFi network, on an Android device (in order to proper calculate the UDP broadcast address strictly for the local subnet).
When the device is connected to an Access Point, the following is properly working:
// Only works when NOT tethering
WifiManager wifi = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
DhcpInfo dhcp = wifi.getDhcpInfo();
if (dhcp == null)
throw new IOException("No DHCPInfo on WiFi side.");
foo(dhcp.ipAddress, dhcp.netmask);
But it doesn't work when it's the android device providing an Access Point though tethering: DhcpInfo seem to contain info set by the DCHP server when the Android device is a client of it, not when it's the Android device itself providing the DHCP service. When in tethering, the most promising solution I could find is:
// No way to get subnet mask
WifiManager wifi = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
WifiInfo info = wifi.getConnectionInfo();
if (info == null)
throw new IOException("No connection info on WiFi side.");
foo(info.getIpAddress(), info.??? /* netmask*/ );
EDIT: WRONG, in my tests even this only works when NOT tethering. While tethering the IP is always 0.
But there's nothing like WifiInfo.getNetMask(), how can I get the subnet mask in that case? (This absence strikes me as really strange, since there's a plethora of other info there. Am I missing something obvious?)
Also, ideally I'd like a solution that doesn't need to discriminate if the Android device is providing tethering, and just get the local IP address and subnet mask, on the WiFi network, in any case, both when the Android device is providing or a client of an Access Point.
Even standard Java (i.e. not Android-specific) NetworkInterface.getNetworkInterfaces(), don't seem to have a way to get the subnet mask (apart from not allowing to discriminate which corresponds to the WiFi). What am I missing?
Best solution I found at the moment:
It baffles me how info/interface about tethering is so cumbersome/hidden to get, and yet not taken into consideration when you get info from WifiManager, or ConnectivityManager for the Wifi type: it all works only when NOT in tethering. I'm actually lost to that branch of investigation.
Best solution I found at the moment is using standard Java NetworkInterface.getNetworkInterfaces(), instead of any Android API.
Experimentally, Android seems smart enough to set to null broadcast for network interfaces to the external mobile network. It actually makes lot of sense since Android silently drop UDP broadcasts involving external mobile network.
// This works both in tethering and when connected to an Access Point
Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
while (interfaces.hasMoreElements())
{
NetworkInterface networkInterface = interfaces.nextElement();
if (networkInterface.isLoopback())
continue; // Don't want to broadcast to the loopback interface
for (InterfaceAddress interfaceAddress : networkInterface.getInterfaceAddresses())
{
InetAddress broadcast = interfaceAddress.getBroadcast();
// InetAddress ip = interfaceAddress.getAddress();
// interfaceAddress.getNetworkPrefixLength() is another way to express subnet mask
// Android seems smart enough to set to null broadcast to
// the external mobile network. It makes sense since Android
// silently drop UDP broadcasts involving external mobile network.
if (broadcast == null)
continue;
... // Use the broadcast
}
}
As for subnet mask, the result from getNetworkPrefixLength() can be coerced into a subnet mask. I used getBroadcast() directly since that was my ultimate goal.
No special permissions seem to be needed for this code (no ACCESS_WIFI_STATE nor NETWORK, just INTERNET).
Primary reference for the code snippet: http://enigma2eureka.blogspot.it/2009/08/finding-your-ip-v4-broadcast-address.html
I have a Android application which consumes a webservice on a local network. There's a config screen where the user inform the server IP address, which is running Apache Tomcat.
I'm looking for a way to auto-detect the server based on the current connected wi-fi network.
i.e: The smartphone's IP is 10.1.1.90 and the server IP is 10.1.1.254.
Is there a way to achieve this? I'm thinking on using ping, but I don't know if is a good ideia.
The way I understand it, you need to discover IP of your tomcat server and connect it using your client.
I am assuming , both the server and client is in your control.
One simple way can be to use jGroups Cluster.
You can make your tomcat discoverable
Client can discover it using the name of the cluster you have provided .Refer the JChannel API that Jgroups uses
I simulated it making following server class
public class TomcatServer {
JChannel channel;
private void start() throws Exception {
channel = new JChannel(); // use the default config, udp.xml
channel.connect("TomcatCluster");
}
public static void main(String[] args) throws Exception {
new TomcatServer().start();
}
}
The simulated client class
public class MobileApp extends ReceiverAdapter {
JChannel channel;
private void start() throws Exception {
channel = new JChannel(); // use the default config, udp.xml
channel.setReceiver(this);
channel.connect("TomcatCluster");
channel.close();
}
public static void main(String args[]) throws Exception {
new MobileApp().start();
}
The client will provide you following information
GMS: address=MACHINENAME-47879, cluster=TomcatCluster, physical address=xxxxx:0:xxx:xxxx:xxxx:xxxx:xxx:xxxx:xxxx
** view: [MACHINENAME-31239|1] [MACHINENAME-31239, MACHINENAME-47879]
Where MACHINENAME-47879 is the client machine and port & MACHINENAME-31239 is the tomcat server name and port
Do you want to detect "a tomcat server" or "your tomcat server" ?
I mean, do you have any way to custom your server ? If it's the case, then you could create a very simple test page on your server (say a "Hello" JSP page), which your Android application could look for.
If your Android gets a "Hello" result with a GET request on http://<tomcat_ip>/hello.jsp, then you may assume that the tomcat is online.
If you can't add this test page, then you can test any page which the server is supposed to serve. (even a 404 page which sometimes is not configured well, and shows the tomcat version...)
Tomcat response headers can contain the xpoweredBy field that would advertise Tomcat if enabled. However it is most often disabled due security considerations, and even disabled by default. You however could re-enable it if you need to auto-detect exactly your Tomcat servers. From the other side, indeed, if you can place a web page on your server, you can simply place a marking page with the agreed signature.
If the server IP is unknown, I would propose the following ways to detect the server on the network:
The most straightforward way is to do the breadcast ping (ping -b broadcast_address where breadcast address can be computed here, for instance). All network devices that are configured so would reply, then verify as explained above which one is the server. However pinging broadcast address requires a rooted phone. Also the router may not support.
Your DHCP service (most likely your router) can often be configured to issue always the same IP address for the same MAC address of your server network card.
If the server is a desktop computer or laptop, it could show its address as QR code on display. It is possible for a smartphone to scan the code from the screen, and this is way easier than to enter IP address through the touchscreen. QR code can also include auto-generated password for extra security.
If there is wireless router with the possible login where both server and client are connected, the internal pages of that router often contain the relevant IP addresses. You would need to implement logging into the router and doing some screen scrapping.
I made an Android app which used a local server in the WLAN. I made the terminal (the phone) broadcast it's own IP address, which the server then picked up.
I used MultiCast class on the phone, which added the ip-address of itself to the payload. The server always has a thread in multicast read class that obains the payload of the packet (which is the terminals ip-address). Set the terminal in datagram read state and send the servers ip-address to terminal.
Maybe are better ways, but a great way to get the ip-addresses of unknown terminals in the network.
The way i had resolved this problem is with the use of enumerations.
public String getLocalIpAddress()
{
try {
for (Enumeration<NetworkInterface> en = NetworkInterface.getNetworkInterfaces(); en.hasMoreElements();) {
NetworkInterface intf = en.nextElement();
for (Enumeration<InetAddress> enumIpAddr = intf.getInetAddresses(); enumIpAddr.hasMoreElements();) {
InetAddress inetAddress = enumIpAddr.nextElement();
if (!inetAddress.isLoopbackAddress()) {
return inetAddress.getHostAddress().toString();
}
}
}
} catch (Exception ex) {
}
return null;
}
}
I am connected to a WLAN, where a special hardware device is connected to as well. I communicate to that device via a socket, since I know its IP.
Is there a was to identify that hardware device in the network by an id? I found out in Java it is not possible to obtain the MAC-address of a connected device. Is there any other alternative?
Thanks,
best regards
Mac addresses should be unique. Maybe you can get needed information from the ARP table.
Command "arp -a" works on Windows and Linux.
But there is a problems:
This is not portable way
The ARP table is quite variable
If the device is behind a router, then this does not work.
In Java you can call NetworkInterface.getHardwareAddress() that will return hardware MAC address
Enumeration<NetworkInterface> enumNicList = NetworkInterface.getNetworkInterfaces();
while(enumNicList.hasMoreElements())
{
NetworkInterface oNic = enumNicList.nextElement();
byte[] baMacAddress = oNic.getHardwareAddress();
String sMacAddress = new BigInteger(1, baMacAddress).toString(16);
System.out.println(sMacAddress);
}
If you don't have any control of the responses of the device, and the device doesn't contain any identifying API calls and such, then just use the IP address and make that IP statically assigned to that device via your router. Then you can either create your own table of IP <-> device list, or even scrape the IP table off your router.
Come to think of it, you could probably get the MAC address the same way - scrape the DHCP table off your router's configuration screen.
I have two computers plugged in the same router of a network which I know supports IPv6. Let's call them "PC-A" and "PC-B
I want "PC-A" to figure out "PC-B"s IPv6 address and vice-versa
The first thing I do is
setSystem.setProperty("java.net.preferIPv6Addresses", "true");
If I then say
InetAddress IPAddress = InetAddress.getLocalHost();
I can get my own address which will be in IpV6 format
However, neither of the following two statements gives me "PC-B"s IPv6 address:
Inet6Address IPAddress6 = (Inet6Address)InetAddress.getByName("PC-B");
InetAddress IPAddress = InetAddress.getByName("PC-B");
I also tried to import
import com.lavantech.net.dns.SimpleDNSLookup;
import com.lavantech.net.dns.DNSLookup
The first one I am using as:
SimpleDNSLookup d = new SimpleDNSLookup();
System.out.println(d.getInet6Address("PC-B"));
and the second one as:
DNSLookup dnsLookup = new DNSLookup("PC-B", DNSLookup.QTYPE_AAAA, DNSLookup.QCLASS_IN, 3000, null);
// Get all Address Records.
ResourceRecord[] ansRecords = dnsLookup.getAAAARecords();
System.out.println(ansRecords[0]);
none of which works.
I also tried to use the following
import org.xbill.DNS.*;
int type = Type.AAAA;
Name name = Name.fromString("PC-B");
Lookup lookup = new Lookup(name, type);
lookup.run();
int result = lookup.getResult();
Record[] answers = lookup.getAnswers();
System.out.println(answers[0]);
// (where, for brevity, i am skipping the parts where I check whether result == Lookup.SUCCESSFUL
Note that if I substitute "PC-B" for, say, "ipv6.google.com" I get all the desired results!
Also note that if I just use InetAddress and Type_A wherever applicable in the above approaches, my program returns "PC-B"s IPv4 address without problem.
What am I missing?
Any help is greatly appreciated!
Your question is -unfortunately- a yet unsolved network problem dealing with host discovery on a local subnet (regardless if that subnet has a router or not).
Your desired output is clearly an IPv6 address, but it is unclear what exactly your input is.
Let's focus on PC-B. How exactly do you identify PC-B? It clear that you call it "PC-B", but that name should be configured somewhere before your PC know that that's its name. Where exactly is that configured? Is that the hostname you set on PC-B itself, or is there a domain name server (DNS) where you have given that name? If it is the name in the DNS system, you can indeed query the DNS system for the AAAA record to get the IPv6 address, but you need the fully qualified domain name (FQDN). E.g. "PC-B.yourdomain.com" rather than just "PC-B".
If you know the MAC address of PC-B, you can use the neighbour discovery protocol (NDP) to find out the IP address of PC-B.
There are network protocols that allow PC-A and PC-B to announce their names themselves, once you configured them on the local machines. Such protocols are called "service discovery" protocols, and your options here are (1) multicast DNS (mDNS) and possibly DNS service discovery (DNS-SD) on top of that; or (2) Simple Service Discovery Protocol (SSDP) in UPnP on the other hand. The advantage is that some operating systems already implement this. E.g. if PC-B is a Mac OS X host, all you need to do is query DNS for "pc-b.local" to get the answer. Unfortunately, while implementations of mDNS exist for Linux (Avahi) and Windows (Bonjour), they're not installed by default. A third alternative is to write your own host discovery protocol, and have your hosts run that protocol.
Considerations are which platforms you want to support, if installing third-party software is an option, if the discovery needs to be secure (the above options are not, look into Secure Neighbour Discovery -SEND- if this is a concern), and what input you have in the first place (the hostname "PC-B", or the type of service that runs on PC-B, e.g. _http._tcp for a webserver).