0

Due to an unfortunate (mis-)configuration issue I am having ~100 hosts of which the IPv6/IPv4 (even the IPv6 link-local) addresses are all the same and which for the moment I cannot change. However, all hosts have unique and known MAC addresses and are in the same broadcast domain. Is it possible to communicate with the hosts individually and simultaneously on the IP-level by crafting the corresponding ethernet frame myself that uses the known MAC address and not a MAC obtained via ARP/...? All (embedded) hosts run a Linux network stack.

Are there wrappers for existing programs like curl that would allow me to even maintain a separate TCP connection with each host allowing me to talk to them via HTTP simultaneously in the given above situation? It seems to me that in theory this should be possible.

Improve this question
2
  • 1
    how can you distinguish between them based on IP and above header alone?
    – Effie
    Commented Dec 17, 2021 at 6:03
  • Map each one at a time per static ARP and change its IP addresses to something unique. You might want to consider DHCP.
    – Zac67
    Commented Dec 18, 2021 at 9:16

3 Answers 3

Reset to default
1

As @AlexD indicated, you must associate manually in your local machine the common IP address a.b.c.d with the desired MAC address xx-xx-xx-xx-xx-xx of each particular remote host so you can connect to it.

In Windows, you can use the arp command in a elevated command shell window:

arp -s a.b.c.d xx-xx-xx-xx-xx-xx

This association is permanent until deleted with arp -d a.b.c.d (as indicated by arp -?).

The commands and options -s/-d in Linux are the same, executed in a shell with root privileges or prefixed with sudo, but only affect the resident ARP cache, so are forgotten at restart (man arp is recommended).

Edit: As @Zac67 stated, there can be only one pair IP/MAC for each host in the local net. This is because the local traffic is done using only the last known MAC address (found via an ARP query or an ARP table lookup) for a given IP address. If there are other machines with the same IP, they won't be recognized.

This will change only either if:

  1. [The association was static (done by the admin with the arp command)] The pairing is changed again by the admin, or forgotten at the restart of this machine if it isn't permanent (then it will change to dynamic). Or,

  2. [The search was dynamic using the ARP protocol.] After some time, the result will be marked as stale and the next connection will provoke a new search in the local net. Then some other host could win the race to give its MAC address.

The manual pairing has higher priority than the automatic one.

It boils down to: We can only have one pair IP/MAC for destination host to have a successful communication. If there are several pairs in the local net, because of a config error or malware/hacking activities, and we are using the ARP auto discovery, we will have intermitent problems or worse.

Of course, the dynamic method with unique IP addresses is preferred; it means less hassle for the admin... ;)

Improve this answer
1
  • You should add that static ARP works with one host at a time, simultaneous connections with multiple hosts are - generally - impossible.
    – Zac67
    Commented Dec 17, 2021 at 8:14
0

You can disable incoming ARP updates on a management machine with arptables and then manually update ARP table with arp for each crippled host one by one.

Improve this answer
0

What you ask is only possible hypothetically, if you crafted your own IP stack.

If you use IP addresses, the IP stack uses dynamic or static ARP to determine the required MAC address for each IP. There can only be one mapping at any given time. There's no way for an application to specify or force a specific mapping for any socket connection. See @Fjor's answer for details.

If you created your own IP stack with an API allowing that IP-to-MAC mapping per socket, then you could do what you're asking.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .