You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After we manually changed the packet to being unicast (the MAC being rewritten to 00:01:01:01:01:01) and retransmitting it, Hyper-V VMSwitch correctly forwards the packet:
Is this intended that way and a misunderstanding on our side or is this a bug in SOEM?
Thanks and kind regards :-)
The text was updated successfully, but these errors were encountered:
SOEM was never tested to be used in a VLAN environment. But as you see, the solution to your problem is very simple.
You can set any source MAC address you like. There is one requirement, the U/L bit must not be set as that is used to differentiate outgoing from returning packets. EtherCAT slaves set the U/L bit to signal they have passed the ESC.
The original intend to set the I/G bit was to be able to use switches as star topology elements. It did work on a few old switches, but nowadays this is very rare to succeed. So consider it legacy.
Hi,
we have discovered that the Hyper-V VMSwitch (we are using this for VLAN segmentation on our test setups) drops all packets coming from SOEM.
After playing around a bit it seems that Hyper-V VMSwitch does not like the src MAC address SOEM is using by default 01:01:01:01:01:01 since it is set to being multicast, which doesn't really make sense for a source address:
After we manually changed the packet to being unicast (the MAC being rewritten to 00:01:01:01:01:01) and retransmitting it, Hyper-V VMSwitch correctly forwards the packet:
Is this intended that way and a misunderstanding on our side or is this a bug in SOEM?
Thanks and kind regards :-)
The text was updated successfully, but these errors were encountered: