2

I have setup a Raspberry Pi 3 (master) connected via USB to two Raspberry Pi Zero's (slaves). I have enabled dwc2 and g_ether on all devices. When I attach the USB's I automatically get IP addresses generated for each USB connection on each device.

For instance the master gets:

usb1: inet 169.254.77.143  netmask 255.255.0.0  broadcast 169.254.255.255`
usb2: inet 169.254.206.101  netmask 255.255.0.0  broadcast 169.254.255.255`

And the slaves get:

slave 1
usb0: inet 169.254.89.28  netmask 255.255.0.0  broadcast 169.254.255.255

slave 2
usb0: inet 169.254.147.186  netmask 255.255.0.0  broadcast 169.254.255.255

With this setup, from each slave I should be able to ping the relative master USB IP address, however from one slave I can ping both master IP addresses, but from the other slave I cannot ping either USB address.

For example: Slave 1 should be able to ping 169.254.77.143, and slave 2 169.254.206.101, however we instead see slave 1 can ping both IP's, but slave 2 cannot ping either.

I've also attempted to set static IP addresses in the /etc/network/interfaces file to resolve this issue, but I was seeing the same problem.

I am trying to make it so the master Pi can send UDP broadcast messages to the slave Pi's, and the slave Pi's can send TCP messages back to master. I have the code capable for this to work, however I need to give the master a broadcast IP address for over USB, and the slaves need the master's USB IP address.

Does anyone have any ideas as what could be causing this issue?

2 Answers2

3

The problem here is that all the addresses are in the same network, 169.254.0.0/16.

Using such addresses is fine for one network, but doesn't work for multiple networks.

The exact reason is that when the client sends a ping, your master is supposed to respond. But where should the response go? The address is in the range 169.254.0.0/16, but there are two routes for this destination, so it picks one of them, the first one. That is the reason why Slave 1 receives a response and Slave 2 doesn't. Actually, the response intended for Slave 2 is sent to Slave 1, but Slave 1 doesn't expect it and just ignores it.

If you need more than one interface, you should either set up static addresses for all involved, or use DHCP on the master (together with static addresses from different networks on the master), and the slaves can get a dynamic address from the DHCP server on the master.

Edit

If you want them to be in the same broadcast domain, if might be a good idea to create a bridge. This also solves the problem with the same subnet on both interfaces.

For a bridge, you need the package bridge-utils.

Manual configuration is as follows:

brctl addbr br0
brctl addif br0 usb1 usb2

This assumes that your interface names are usb1 and usb2. It creates a new interface br0.

I'm not that familiar with Debian network configuration, but you need something like this in /etc/network/interfaces:

iface usb1 inet manual

iface usb2 inet manual

iface br0 inet static
    bridge_ports usb1 usb2
    address 169.254.1.1
    netmask 255.255.0.0

This configures the bridge br0 an assigns a static address.

RalfFriedl
  • 2,188
  • 2
  • 10
  • 11
  • When you say "have the static addresses for all involved", how do you set static IP's for USB? Just in the /etc/dhcpcd.conf? Would this allow each device to exist in the same network? As I want to broadcast messages from the master to all the slaves. – Michael Murray May 31 '19 at 15:23
  • 1
    Then a bridge might be the solution for you, I added some information about bridge configuration. Addresses are not assigned to USB, they are assigned to network interfaces. Those interfaces might use USB, Ethernet, WLAN or whatever, the network layer doesn't care. – RalfFriedl May 31 '19 at 18:27
  • This is incorrect. 169. addresses are NOT in any network. They are Link-local address and are not routable; nothing you can do will make them routable. – Milliways May 31 '19 at 22:45
  • 1
    @Milliways You are entitled to your opinion, however it is merely a convention to use these addresses as link-local. Nothing in the network stack prevents a route to addresses in that range to point to a gateway, although I didn't suggest to actually do that, so I don't understand why you feel the need to deny it regarding what I wrote. – RalfFriedl Jun 01 '19 at 09:32
  • @RalfFriedl the bridge resolved the issues I was having. Thank you! – Michael Murray Jun 02 '19 at 22:28
0

The addresses you listed are Link-local address i.e. NO IP address has been allocated, and they are not routable.

DO NOT attempt to "set static IP addresses in the /etc/network/interfaces" - as noted in the file itself

Please note that this file is written to be used with dhcpcd

For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

See How to set up networking/WiFi

See How to set up Static IP Address

Mind you, just allocating IP addresses does NOT magically let you route traffic between interfaces, but it is unclear what you are actually attempting to achieve.

You say "I have enabled dwc2 and g_ether on all devices" - it is unclear what devices, but this is not possible on a Pi3 which includes a hub.

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • I have updated what I am attempting to achieve. I have also removed the dwc2/g_ether stuff from the Pi 3. How do you define how you can route traffic between the USB interfaces then? – Michael Murray May 31 '19 at 11:58
  • You are still using Link-local address - it is possible to run some services (e.g. ssh) over these, but you would be better to allocate IP addresses; I would probably implement a DHCP server on the Pi3, but your question lacks sufficient context to see what would be the best solution. – Milliways May 31 '19 at 22:50