3

I'm working on an Ethercat master written Go. The underlying library is at http://github.com/distributed/ecat and contains one link level driver, using UDP and multicast. I'm having trouble to get this link level driver to work consistently across multiple platforms (OS X, Windows, Linux) and different networking configurations.

For those not familiar with Ethercat, here's how it works. Ethercat is an industrial bus system based on Ethernet. There's one bus master and potentially many slaves, which are connected into a logical ring. The master can be built from off-the-shelf hardware, i.e. with normal Ethernet interface cards. The master sends a packet on its Ethernet interface, the slaves modify the packet on the fly and after passing through all the slaves, the master receives the packet on the same network interface that sent it. Depending on the number of slaves, the network interface might start to receive the packet while it is still transmitting the very same packet. There are two possible formats for Ethercat frames. The first is an Ethernet packet with a special ethertype. The second is a UDP packet destined for port 0x88a4.

Depending on the commands contained in an Ethernet packet, the slaves may or may not modify the packet's Ethercat data. Apart from changing Ethercat data, the only thing about the packet that is changed is that bit 1 of the Ethernet destination address is set to 1. The IP header of the packet is not touched by the Ethercat slaves.

My code works as follows. I join a multicast group, say 239.255.65.10 on interface xyz, where I connected my Ethercat slaves. To exchange data with the bus, I send a packet, let's call it pA on this interface to 239.255.65.10. The OS fills in the source address, say the IP address 192.168.5.2 of interface xyz. After the packet passed through the bus and was possibly altered, it's now packet pB. The IP header still has a source of 192.168.5.2 and a destination of 239.255.65.10. Depending on the host's networking settings, this packet might or might not reach my application. In the cases where it does not reach my application, say when rp_filter is set, on Linux, packet pB is rejected because it looks like it originated from my machine, but we shouldn't be receiving our own packets over the network.

What steps can I take to reliably receive the processed packet pB? Please note that I'm not speaking about loopback - loopback is about receiving packet pA, my question is about receiving pB.

distributed
  • 366
  • 4
  • 13
  • Well, quick googling for multicast+rp_filter turns up that setting `rp_filter` to 1 reliably disables receiving multicast traffic in your case, so while I don't have a real answer, it appears that it could be "no, you have to warn the user in the README file". – kostix Feb 25 '14 at 13:33

0 Answers0