2

I have an RPi 3 running Raspbian 10 (Lite, headless). It is connected to my LAN via eth0 which is working fine.

Now I need to also connect the RPi to a PLC with very limited configuration options (basically: either DHCP client or fixed IP). I plugged in a USB Ethernet adapter, which shows up as eth1, and I am trying to configure a connection with fixed IP addresses.

Some background, as requested in the comments: a PLC is a Programmable Logic Controller, a device commonly used in industrial control applications. It doesn't really matter, the main point is that it is closed source and I have very limited configuration options: I can set it to use DHCP for IP configuration (i.e. as a DHCP client - it doesn't have a server), or assign a fixed IP and netmask.

Here is an attempt to depict the situation with ASCII graphics:

   PLC (fixed IP 192.168.60.2; alternative: DHCP client)
    ^ 
    |
    | 
    v   eth1 (fixed IP 192.168.60.1)
   RPi
    ^   eth0 (DHCP client, using default dhcpcd config)
    |
    | LAN with DHCP server + gateway to internet

I configured the PLC to use 192.168.60.2 (fixed IP) and added the following lines to /etc/dhcpcd.conf:

interface eth1
inform 192.168.60.1/24

ifconfig shows that eth1 does indeed get 192.168.60.1, but I can still not reach the PLC at 192.168.60.2.

I suspect that messages to 192.168.60.2 are not routed to eth1:

pi@raspberrypi:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    202    0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
pi@raspberrypi:~$ 

Manually adding a route fixes the problem:

pi@raspberrypi:~$ sudo route add -net 192.168.60.0 netmask 255.255.255.0 dev eth1
pi@raspberrypi:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    202    0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.60.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
pi@raspberrypi:~$ ping 192.168.60.2
PING 192.168.60.2 (192.168.60.2) 56(84) bytes of data.
64 bytes from 192.168.60.2: icmp_seq=1 ttl=255 time=10.6 ms
64 bytes from 192.168.60.2: icmp_seq=2 ttl=255 time=2.23 ms

Is this the right way to do this, and if so, how do I automate this? Is there a better way, maybe by adding something to dhcpcd.conf?

One possible alternative would be to run a DHCP server on eth1 on the RPi, and configure the PLC as a DHCP client. The challenge would then be to make sure that the PLC always gets the same IP address, even if I replace it with a different PLC (different MAC address). Note: there will always be only one PLC; this is a point-to-point connection.

The reason why I made this a point-to-point connection separate from the LAN, is that the connection with the PLC needs to work even if there is no LAN (network down or misconfigured). I have very little control over the LAN, and the connection to the PLC needs to be very reliable.

8
  • PLC - what is that exactly? Do you mean either - or neither?
    – Seamus
    Commented Jun 17, 2021 at 19:17
  • PLC is a Programmable Logic Controller, a device commonly used in industrial control applications. It doesn't really matter, the main point is that it is closed source and I have very limited configuration options: I can set it to use DHCP for IP configuration, or assign a fixed IP and netmask.
    – ygramoel
    Commented Jun 17, 2021 at 19:20
  • It would be better to edit your question to add this info - but it's strictly your choice. Not everyone reads the comments...
    – Seamus
    Commented Jun 17, 2021 at 20:07
  • And so I gather from your question that the 192.168.0.0 network is not the network used by your LAN - is that correct?
    – Seamus
    Commented Jun 17, 2021 at 20:11
  • If the PLC has a DHCP server why are you making life more difficult by fiddling with static? What happens if you omit from dhcpcd?
    – Milliways
    Commented Jun 17, 2021 at 22:40

3 Answers 3

1

After more research, I found the following solution:

  1. Keep the lines in /etc/dhcpcd.conf:
interface eth1
inform 192.168.60.1/24
  1. Create an executable file /etc/dhcpcd.enter-hook with the following content:
#!/bin/bash
if [ "$interface" = "eth1" -a "$reason" = "CARRIER" ]; then
  ip route replace 192.168.60.0/24 dev eth1
fi

This will restore routing to the 192.168.60.0/24 subnet at reboot as well as when the USB ethernet adapter is plugged in.

This solution - without predictable network interface names - will work as long as there is only one additional network interface (in addition to the on-board eth0), even if the adapter is replaced by another one with different MAC.

EDIT: When the ethernet adapter is plugged in and connected to some other device with an ethernet cable, the following lines appear in /var/log/syslog, even without the above lines in /etc/dhcpcd.enter-hook:

Jun 24 17:31:25 iono dhcpcd[955]: eth1: probing address 192.168.60.1/24
Jun 24 17:31:25 iono dhcpcd[955]: eth1: soliciting an IPv6 router
Jun 24 17:31:30 iono dhcpcd[955]: eth1: using static address 192.168.60.1/24
Jun 24 17:31:30 iono dhcpcd[955]: eth1: adding route to 192.168.60.0/24

This seems to indicate that dhcpcd attempts to set up routing on its own for the subnet of the fixed IP, but fails. Is this a bug in dhcpcd, or my misunderstanding?

3
  • I think this is a good answer. You've a bit of a special case with your network, and you've approached it correctly - reading and experimentation to put light in the dark corners. FWIW, I doubt it's a bug - Roy Marples is thorough from all I know, but you never know. More likely IMHO is the somewhat arcane nature of the DHCP - refer to RFC2131 - and this Q&A for substantiation.
    – Seamus
    Commented Jun 25, 2021 at 3:50
  • You should be sure to select your answer as the accepted answer as soon as you're able (the system may require you to wait a day or two before the check box is enabled). Accepted answers help reduce the noise level here - it seems the system periodically dredges many un-answered questions up and we have to see them floating downstream again :(
    – Seamus
    Commented Jun 25, 2021 at 6:52
  • One final thought: Some people don't like dhcpcd, and some do. I put myself in the latter camp because it seems more straightforward to me than the stuff in Ubuntu. As you've seen, some of the older methods of net configuration are deprecated now, and it's become a Tower of Babel situation to get good information. There are some alternatives to dhcpcd for RPi OS - perhaps systemd-networkd has a distinct advantage in that it works on all (most) Linux distros.
    – Seamus
    Commented Jun 25, 2021 at 7:23
1

Adding a route works fine - as you've seen. If you want to make the route permanent, one way to do this is add it to /etc/dhcpcd.exit-hook - per the arch-linux wiki page on dhcpcd (good resource). Another possible way to do this is to add the route to a file in /etc/network/interfaces.d. I've not tried this myself, but the contents of /etc/network/interfaces suggests that it will.

Another way to do it would be to assign your PLC an address on your LAN (I'm assuming from the wording of your question that your LAN subnet is different than the one you've assigned to your PLC). If all your devices are on the same subnet, no routing is necessary.

5
  • Adding a route works indeed - but how do I make it permanent? The route disappears not only after a reboot, but also when I disconnect and then reconnect the USB ethernet adapter that correcponds to eth1.
    – ygramoel
    Commented Jun 18, 2021 at 7:26
  • It is essential that the connection from the RPi to the PLC continues to work even if there is no LAN
    – ygramoel
    Commented Jun 18, 2021 at 7:27
  • @ygramoel: I gather you've found an answer to the permanent static route question, so I'll leave this as is.
    – Seamus
    Commented Jun 18, 2021 at 17:30
  • I added some info that I found in syslog to my answer; you may want to have a look @Seamus
    – ygramoel
    Commented Jun 24, 2021 at 20:49
  • @ygramoel: I think I mentioned in another thread that systemd-networkd might be a good solution for your use-case. I failed to mention that RPi SE has a good how-to resource on systemd-networkd.
    – Seamus
    Commented Jun 27, 2021 at 6:10
0

I suggest you Enable predictable network i/f names in the Advanced option of raspi_config. This avoids a race condition which can result in the wrong interface being configured.

If you want an interface to not install any default routes (often used in conjunction with a static IP address) specify

nogateway

Otherwise traffic may be sent on the wrong route.

See Prevent dhcpcd from configuring an interface and Predictable Network Interface Names in How to set up networking/WiFi

4
  • I am not convinced that enabling predictable network interface names is a good idea in this case. You could not know the context of this project of course, but the same configuration should continue to work when I replace the USB ethernet adapter with another one, having another MAC address. AFAIK, predictable names include the MAC address, so replacing the USB ethernet adapter would require editing the configuration.
    – ygramoel
    Commented Jun 18, 2021 at 7:40
  • There is currently a default route over eth0, which is exactly what I want; the gateway is on the LAN connected to eth0. The only extra thing I need is that packets for the PLC (i.e. for the 192.168.60.0/24 subnet) should be routed to eth1.
    – ygramoel
    Commented Jun 18, 2021 at 7:43
  • Which is precisely what I suggested. Just specify nogateway on eth1 (although without Predictable Network Interface there is no guarantee that eth1 will be the adapter connected to PLC)
    – Milliways
    Commented Jun 18, 2021 at 7:55
  • I tried adding nogateway. There is no change in the routing, and the PLC is still not reachable. All traffic - including traffic for the 192.168.60.0/24 subnet - is still routed to eth0
    – ygramoel
    Commented Jun 18, 2021 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.