> Hi Microchip, > > as ACL based blocking of PTP traffic seems not to work, I tried to install MAC > based static lookup rules on the switch I successfully managed to block other > non-PTP traffic, but for PTP the lookup table entry (see below) seems not to > work. Incoming SYNC messages on port are still forwarded to port 2. > > The table entry is based on the multicast MAC used for PTP. With PTP > domains!=0 > there could be 128 possible MAC addresses that needs to blocked (but the > switch > has only 16 entries in the static table). Is there any way to block the whole > PTP multicast address range (01:00:5E:00:01:81-01:00:5E:00:01:ff)? The data > sheet > mentions that the static address table can be used for multicast addresses, > so there should be a way. > > Alternatively, is there a hidden "disable TC" setting which disables the > transparent clock entirely? The 1588 PTP engine in the KSZ switches was designed to be controlled closely by a PTP stack, so it is a little difficult to use when there is a layer of kernel support between the application and the driver. The default mode to use should be 1-step E2E where the switch acts as an E2E Transparent Clock. The 16-bit register 0x514 specifies the basic operation mode of the switch. Bit 0 is for 1-step clock mode. Bit 1 is for master mode, which should be off when the clock is acting as a master. Bit 2 is for P2P mode. Bit 7 stops the automatic forwarding and every PTP message goes to the host port. This is the mode to use when the switch acts as a Boundary Clock or 2-step Clock. When master mode is on Delay_Resp will not be forwarded to the host port. When master mode is off Delay_Req will not be forwarded to the host port. When P2P mode is off Pdelay_Req/Pdelay_Resp/Pdelay_Resp_Follow_Up will not be forwarded to the host port. When P2P mode is on those messages can be sent and received even though the port Is closed for normal communication. Bit 5 recognizes L2 PTP messages and the switch acts accordingly. Bit 4 is for UDPv4 while bit 3 is for UDPv6. It is rather pointless to actively filter certain PTP messages through other means. It is better to leave the kernel PTP receive filter as coarse as possible. When using P2P in 1-step clock mode the port id in the PTP header is automatically changed by hardware to be the same as the real port, so it is useless to arbitrarily use a different port id. The original intent is to send 1 Pdelay_Req and receive several Pdelay_Resp in each port. The calculated peer delay from the port needs to be programmed to the port register so that the Sync message can be compensated correctly while it travels through the switches. This poses a problem as the driver normally does not do the calculation. The 2-step clock mode avoids some of the mentioned issues. However there are some hardware bugs associated with this operation mode and it is not recommended to use. For some profiles that require 2-step operation like gPTP there are ways to workaround. For Sync it is quite simple to send Follow_Up after it even though the Sync contains the transmit timestamp. The Follow_Up just repeats that information. For 2-step Pdelay_Resp it is harder as the hardware puts the turnaround time in the correction field. The driver workaround is to report the transmit timestamp differently such that it is the same as Pdelay_Req receive timestamp so that the net calculation of the peer delay is just the same as receiving 1-step Pdelay_Resp. I will try my own implementation to see how these steps can be done.
