1

I have need to attach the two robotic devices to my computer, and for this I would like to use the two network cards connecting to these different pieces of hardware. Both devices happened to use the same network (ip addresses 10.0.0.70 and 10.0.0.21, netmask 255.255.255.0 in both cases).

I have discovered that if I configure and put up the network of any single card, it works no problem: I can ping the robotic device, and I have all other connectivity to it. However as soon as I put the second card up, only one of the two is working. I tried to given the main computer different IP addresses, tried to give the same, makes no difference. I tried to specify IP address of the host computer as the gateway, different for each card, the same, no difference at all. Even ping does not work on one of the cards when both are up, and even if I specify when pinging which interface to use.

My kernel is 4.15.0-39-generic #42~16.04.1-Ubuntu SMP Wed Oct 24 17:09:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux.

Both network cards can work together if I assign them to the different networks. However it would be preferred not to change the network settings on the side of the robotic devices. I do not need to route packets between these two cards.

Here is the working configuration I got:

enp3s0    Link encap:Ethernet  HWaddr 18:d6:c7:00:d9:3e  
          inet addr:10.0.1.30  Bcast:10.0.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16929681 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56504 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1219898415 (1.2 GB)  TX bytes:5267812 (5.2 MB)

enp6s0    Link encap:Ethernet  HWaddr 18:d6:c7:01:69:35  
          inet addr:10.0.0.22  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::1ad6:c7ff:fe01:6935/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:52316 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16935487 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4325056 (4.3 MB)  TX bytes:1220948325 (1.2 GB)

It stops working as soon as I change the IP of the first device to 10.0.0.30 (and broadcast address changes into 10.0.0.255).

I have just tried under Kali Linux live distribution, even there it does not work. Under Kali Linux

ifconfig eth0 10.0.0.21 netmask 255.255.255.0 up
ifconfig eth1 10.0.0.70 netmask 255.255.255.0 up

Again, I would expect that at least ping -I should work but nope, to ping any one, another must be down. How can any simple switch have multiple physical ports connected to the same network and a large computer cannot?

h22
  • 389
  • 3
  • 16
  • Tip: Use `ip a s` instead of ifconfig – Panki Dec 06 '18 at 07:56
  • 1
    I don't understand. If the two cards are truly connected to the same network, then the setup should work with no problems. If the two cards are actually connected to different networks, then you are lying to the operating system and I don't see how you would expect it to work. (If the cards are not connected to the same network but you lie to the OS and pretend that they are, how can the poor OS guess which card to use to talk to which robot?) – AlexP Dec 06 '18 at 09:58
  • Do you have a typo there? You've shown a working configuration where the first device has `inet addr:10.0.1.30`, then say that it "stops working as soon as I change the IP of the first device to 10.0.1.30". – JigglyNaga Dec 06 '18 at 10:25
  • @AlexP I at least expect ping to work when I specify the interface. Robots have different IP addresses, why OS cannot probe the both cards, seeing them as parts of the same network? Every switch can do this thing. – h22 Dec 06 '18 at 11:59
  • 2
    Why not connnect both devices to the same network interface, if they're in the same network IP range? Otherwise you need to add the interfaces to a bridge and assign the IP address to the bridge, which is sort of the way a switch does it. – wurtel Dec 06 '18 at 12:18
  • In a real world device, it is way nicer to have two network connectors on the same box (two network cards) than the switch hanging on the tail out of the box. – h22 Dec 06 '18 at 12:31
  • 1
    @h22: A switch does it because by definition all the interfaces are part of the same physical network. When you tell the OS that two interfaces are part of the same network, the OS then feels free to use whatever interface it want to talk to any host on the same network. If two interfaces are actually on two different networks (i.e., there is no layer 2 path between them) then it is a mistake to pretend that they are part of the same level 3 network. – AlexP Dec 06 '18 at 13:11
  • 1
    Possible duplicate of [Linux Source Routing, Strong End System Model / Strong Host Model?](https://unix.stackexchange.com/questions/258810/linux-source-routing-strong-end-system-model-strong-host-model) – Centimane Dec 06 '18 at 13:35

3 Answers3

3

By default, Linux's IP protocol driver uses an optimization that has the technical name of "weak end system model" or "weak host model". See this question for more details.

What it boils down is, when you configure two NICs with IP/netmask combinations that belong to the same block of IP address space, the code that is responsible for routing of outgoing IP addresses will assume it means both those NICs are connected to the same physical network segment, and therefore either of them can be used to talk to any host that has IP address in that block. And then it just uses the interface that happens to be listed first in the routing table for all outgoing traffic to that network segment. It does not have the concept of multiple distinct physical networks using copies of the same IP address space.

If your system happens to have the reverse path filtering (/proc/sys/net/ipv4/conf/*/rp_filter) enabled, it might block you from pinging one of the robots even if you specify the network interface (say eth1): when the answer comes in through eth1, the reverse path filter sees that the normal routing to that source IP would go through eth0 and therefore this incoming packet on eth1 must be bogus. You can see if this is happening if you enable the log_martians setting: 

for i in /proc/sys/net/ipv4/conf/*/log_martians; do
    echo 1 > $i
done

Then attempt to ping your robots, and then check the end of the dmesg output: you might see messages about dropped packets.

Your situation would require the routing to take the source IP address into account when deciding which NIC to use for outgoing packets, and so to behave according to what is called "strong end system model" or "strong host model" instead. Well, Linux can do that using the "advanced routing" functionality, but it is definitely not the default, and is quite tricky to configure. See my answer in the above-mentioned question for a configuration recipe if you really want to do it.

However, since the IP addresses of the robots are not overlapping, the simplest solution in terms of software configuration would be to get a small cheap network switch (or even a hub) and plug both robots and one network cable from the computer into it.

Or if you want simplicity in terms of minimal amount of hardware, then just configure the robots to use different IP segments if you want to wire them directly to multiple NICs on the same computer.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • The answer in the link you provided is the correct one, but answers shouldn't be links. I'd recommend either adding the relevant info into this answer, or flagging the question as duplicate. – Centimane Dec 06 '18 at 13:34
  • Yeah, I thought about just flagging this as a duplicate, but the other one did not have quite the right sort of introductory information. I'm happy with this one flagged as a duplicate, and I think I might refine my answer at the other question to better serve as a landing point for other questions like this. – telcoM Dec 06 '18 at 15:34
2

As the robot devices have a different IP, the simplest way would be to create a Linux bridge with the two ethernet interfaces as ports. Something along the lines of

ip link add name br0 type bridge
ip link set enp3s0 master br0
ip link set enp6s0 master br0

Then set a single IP address on the internally facing br0 interface:

ip addr add 10.0.0.1/24 dev br0

and you should be good to go, without a switch hanging out of the tail of the box, but everything still on the same network.

And please, please, don't use Kali Linux for such things. Read this, and do yourself a favour and switch to some distro (Debian-based, as Kali is also Debian-based) that is intended for daily work. You will run into a lot less trouble. And all the shiny tools Kali has can also be installed.

dirkt
  • 31,679
  • 3
  • 40
  • 73
1

For 21 and 70 you can use two nonoverlapping subnets 10.0.0.0/26 and 10.0.0.64/26 (/26 = mask 255.255.255.192). Assuming no other interfaces include 10.0.0.0/25.

dave_thompson_085
  • 3,790
  • 1
  • 16
  • 16