0

I am trying to find out whether the machines in a network are running a certain app. More like, I am trying to resolve addresses of nodes in a network.

I built a small code based on ARP, but it works only on a local network(same subnet). What I want to do is resolve addresses out of the subnet i.e. all other nodes.

I read these answers: UDP broadcast packets across subnets and Broadcast on different subnets

But they all talk about changing router setting or creating a multicast network.

  1. From what I read for multicasting to work, I need to create a multitask network beforehand. Is it really necessary?
  2. And for changing router setting, does it really have to be a "special" router?

This is all for a college assignment and would be demonstrating it probably on an ad-hoc network or something like that. I am open to ideas to solve the original problem.

PS: 1. I am a beginner in networking so do excuse me for any fault or misinterpretation.

  1. I am using sockets and C(No other option).

Edit 1: I am well aware ARP is useless outside the subnet. I mentioned it because I used it and it helped explaining the problem.

Edit 2:

The original problem is:

Building a chat application, nothing fancy sending messages from one point to another, without using a central server of any kind. Not even a hybrid network with a central store is allowed.

i.e. if A and B are two clients, A should directly connect to B and vice versa. I did some research and decided to use P2P architecture. And now I am stuck to how will A discover address of B. If I know the subnet of B, I can brute force and locate B but since I don't have such information what do I do?

  • You may be trying to solve an [X-Y problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). Why don't you explain why you want to do this; what is the real problem you are trying to solve with this solution? We may be able to give you a better way to accomplish the real task. – Ron Maupin Nov 17 '17 at 22:58
  • @RonMaupin check edit-2. –  Nov 18 '17 at 03:19
  • That is like wanting to call your friend without knowing your fiend's phone number. For telephones, we have directory services (411), and for networks, we have domain name services (DNS). Assume there are not directory services for telephones; no place where you can look up telephone numbers. How would you propose to call your friend if all you know is that he has a telephone? You are in the same situation with your application. That is why you register central information. We do that all the time with DNS. – Ron Maupin Nov 18 '17 at 05:01
  • Exactly. That is what I wrote in my design paper. Apparently, it was kind of rejected. Keeping that aside, can you help? –  Nov 18 '17 at 05:27

3 Answers3

1

ARP is not intended to be routed outside the local network, where in IPv4, the "local network" typically corresponds to a subnet. You should not expect ARP traffic to transit routers from inside to outside or vise versa.

Similarly, UDP broadcasts generally do not propagate outside the local network, and it's a good thing that they don't, for reasons related to both security and traffic volume.

  1. From what I read for multicasting to work, I need to create a multitask network beforehand. Is it really necessary?

Basically, yes. Your routers need to be configured to support multicasting (which may be their default). All participants need to agree on and join the same multicast group. There might not be a need for any new networking hardware, but multicast communication has its own protocols and network requirements; it is not merely a broadcast that can traverse network boundaries.

  1. And for changing router setting, does it really have to be a "special" router?

If you mean changing router settings so that UDP broadcasts are routed between networks, you do indeed need a router that exposes this capability. But I urge you not to do this, as it will let broadcasts from all other sources, for all other reasons transit the router, too. At minimum, this will significantly increase the noisiness of all networks involved, but it could produce bona fide misbehavior of applications and services other than yours.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • So is there any other way to resolve addresses outside the subnet? –  Nov 17 '17 at 17:55
  • 2
    @Dagger, If by "resolve addresses" you mean "resolve [machine] *names* to IP addresses" then yes, there are interfaces to the system's name resolver. On POSIX systems, the preferred one would be `getaddrinfo()`. But I think you're talking instead about *discovering* machines on the network. If you want to do this at the network level, as opposed to standing up a central service to mediate, then your options are limited. I'm not prepared to say that there's no solution at all at that level, but I don't think there's any *easy* solution. – John Bollinger Nov 17 '17 at 18:45
  • Yes, discovering machines. And yes, I've got no central server. –  Nov 17 '17 at 18:55
1

The Limited Broadcast (255.255.255.255, which is used by ARP requests as the destination address, and ARP only works for IPv4 on the local LAN) cannot cross a router, and a Network Broadcast (last network address, where the host is all ones) by default cannot cross a router (Directed Broadcast) because it is a security risk (see RFC 2644, Changing the Default for Directed Broadcasts in Routers).

Some routers can be configured to forward directed broadcasts, but this can be dangerous.

Multicast is a form of broadcast. Multicast routing is very different than unicast routing, and every router in a path must be configured for multicast routing. Also, hosts must subscribe to a multicast group before they will even listen for packets from a multicast group. Additionally, there are some multicast groups that all hosts listen for, but those are link-local multicasts that cannot be forwarded off the local LAN.

Community
  • 1
  • 1
Ron Maupin
  • 6,180
  • 4
  • 29
  • 36
  • So is there any other way to resolve addresses outside the subnet? –  Nov 17 '17 at 17:56
  • If you know the network and mask, you already know all the possible addresses in the network. – Ron Maupin Nov 17 '17 at 18:05
  • That's is the point. I don't. I have to write a resolver which will go around the network(a) looking for valid addresses. –  Nov 17 '17 at 18:15
  • If you don't know that, you can't send anything to the network, anyway. You must know the destination network in order to send packets to the network. – Ron Maupin Nov 17 '17 at 18:18
  • We've apparently strayed away from what I am trying to do. I want to find all addresses of all the machine in the network. I want an address resolver, dedicated packets will be sent later. –  Nov 17 '17 at 18:22
  • To get anything from a host on a different network, you must either send something to the other network and get a response, or you must have something on the other network to send something to you. For example, you want to do this for my network. You must first know an address on my network, and know the mask in order to know how many possible hosts are on my network. – Ron Maupin Nov 17 '17 at 18:31
  • What if I take guesses and send a packet over the network. NACK implies no address, ACK implies positive. Well if I look at it this way it's simple broadcasting. –  Nov 17 '17 at 18:54
  • That's not broadcasting, and what protocol are you using? Most protocols don't have NACKs, and you would need to know the destination address in order to populate a packet's destination address to send a packet to even get an ACK. I really think you need to learn more about the network stack layers, and how networks work before you start trying to write network applications. – Ron Maupin Nov 17 '17 at 18:58
  • Point taken. Upvoted for your time and knowledge. Thank you very much. –  Nov 17 '17 at 19:09
  • there is always the brute force way of taking the target subnet IP and mask, calculating the starting and ending IPs of that subnet, and then send a UDP packet to every single IP on a given port. There is an ICMP reply if a packet can't be delivered. – Remy Lebeau Nov 17 '17 at 19:46
  • @RemyLebeau, that's what I was trying to get around to, but it is clear from the comment that he doesn't have the network and mask: "_If you know the network and mask, you already know all the possible addresses in the network. – Ron Maupin_" To which he replies: "_That's is the point. I don't. I have to write a resolver which will go around the network(a) looking for valid addresses. – Dagger_" – Ron Maupin Nov 17 '17 at 19:55
  • @RemyLebeau, Ron: Could you please elaborate on the brute force way? Is it possible to do without having prior knowledge of subnet and their settings? –  Nov 18 '17 at 03:08
  • No, you would need to try every address on the network, but to do that, you would need to know the network address and mask. IP packets are routed at layer-3 by the destination address in the packet header. If you have no address to try, then you cannot send the packet. You can broadcast and multicast on your local network because you are on the same layer-2 network, but you need layer-3 to get between networks. – Ron Maupin Nov 18 '17 at 04:55
0

Adding to what other answers have provided:

ARP is not useful for a system in another subnet. Even if you were able to send an ARP request to a system in the other subnet, and receive its response somehow -- providing you with that system's MAC address -- you could not use it to send a packet to that system because Ethernet does not provide a routing mechanism, and so the system will never see any Ethernet packet you address to it.

If you are simply trying to identify which systems within another IP subnet are live, you can probably do this by other means. Take a look at the nmap command, for example. It supports a wide variety of IP communications methods that will be routed to the other subnet and can often detect what machines are present and which services are available on the machines found.

And you can of course duplicate what nmap does yourself. For example, if you want to find out which systems in subnet 192.168.10.0/24 are listening on TCP port 80, one way is to simply attempt to connect to port 80 on each system in that subnet. In general, there are four answers you may receive back:

  1. Connection success (No error: the machine is present and there is a program listening to that port)

  2. Connection refused (errno ECONNREFUSED: the machine is present but there is no program listening to that port)

  3. No route to host (EHOSTUNREACH: there is no machine answering to that IP address)

  4. No response (ETIMEDOUT: several reasons why this can happen; for example, the system could have firewall settings causing it to simply ignore the request)

(And there are other less likely possibilities as well.) Using other IP access methods (ICMP/ping, UDP packets) will have a different matrix of possible results.

As others have explained, multicast mechanisms would only be helpful for discovering a set of cooperating machines that are pre-configured to join a multicast group.

Gil Hamilton
  • 11,973
  • 28
  • 51
  • Of course, he needs to know the network and mask of the other network in order to attempt to communicate with the devices on the other network, but the comments suggest that he doesn't know that information. Also, hosts on another network may use a layer-2 protocol that doesn't use MAC addresses, which is another reason that ARP would not work. – Ron Maupin Nov 17 '17 at 18:52