> -----Original Message----- > From: Robert Carter [mailto:robert.car...@octoscope.com] > Sent: Friday, March 15, 2019 11:18 AM > To: Keller, Jacob E <jacob.e.kel...@intel.com>; > linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] mcast_bind patch > > > It sounds like the problem isn't "it picked the subnet I didn't want" > > but rather "different instances of ptp4l didn't consistently pick the > > same subnet, but I don't really care which one they pick as long as > > it's stable"? > > > > If it's the former, I'd rather see some sort of option that lets you > > specify the subnet. However, being deterministic is reasonably > > useful. > > > > Is my description of the second option accurate? Can you describe the > > symptoms that happen when the wrong subnet is chosen? > > This issue and patch precede me, and the historical information is > incomplete, so I recompiled without our patch and ran some tests. > > I'd put the problem in the "it picked the subnet I didn't want" bucket. > Worse, it (ptp4l) also picked the "wrong" interface. > > Without the patch, ptpl4 is sending Sync and Announce messages out the > incorrect interface and using a source IP address that isn't on the "-i" > argument interface. > > ptp4l is bound to eno1 which has two address: > 169.254.52.4/16 > 169.254.53.4/16 > > But Sync and Announce traffic is being sourced from 10.10.100.188, which > is on en02. Oy vey! > > Note, I'm building off the 2.0.0 tag, but that makes no difference. The > multicast binding code hasn't changed. >
That seems weird. We should be obtaining the interface index using sk_interface_index. I suspect that code is what is wrong. > Below is a data dump. > > Rebuilding with the patch back in then traffic is sourced from the > correct interface. With multiple IP addresses on the interface, it > appears the traffic is sourced from the IP address with the lowest address. > > = = = = = = = = = > > octoscope@SuperMicro:~$ ps ax | grep ptp > 2003 ? Ss 0:00 /usr/local/sbin/ptp4l -i eno1 -f This command indicates it should be only using eno1. I suspect the code to bind to a specific network device is what should be investigated and fixed. Thanks, Jake > /usr/local/etc/linuxptp/ptp4l.conf -m -q > 3850 ? Ss 0:00 /usr/local/sbin/phc2sys -s CLOCK_REALTIME -c > /dev/ptp0 -f /usr/local/etc/linuxptp/ptp4l.conf -m -q -w > > = = = = = = = = = > > octoscope@SuperMicro:~$ ethtool -T eno1 > Time stamping parameters for eno1: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > > = = = = = = = = = > > octoscope@SuperMicro:~$ ip addr > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > group default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP > group default qlen 1000 > link/ether ac:1f:6b:1b:8b:c0 brd ff:ff:ff:ff:ff:ff > inet 169.254.52.4/16 brd 169.254.255.255 scope link noprefixroute eno1 > valid_lft forever preferred_lft forever > inet 169.254.53.4/16 brd 169.254.255.255 scope link secondary > noprefixroute eno1 > valid_lft forever preferred_lft forever > inet6 fe80::520a:9c21:95be:5b0a/64 scope link noprefixroute > valid_lft forever preferred_lft forever > 3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP > group default qlen 1000 > link/ether ac:1f:6b:1b:8b:c1 brd ff:ff:ff:ff:ff:ff > inet 10.100.100.188/24 brd 10.100.100.255 scope global dynamic > noprefixroute eno2 > valid_lft 259006sec preferred_lft 259006sec > inet6 fe80::d8e:f266:544b:7274/64 scope link noprefixroute > valid_lft forever preferred_lft forever > 4: eno3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state > DOWN group default qlen 1000 > link/ether ac:1f:6b:1b:8c:ec brd ff:ff:ff:ff:ff:ff > 5: eno4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state > DOWN group default qlen 1000 > link/ether ac:1f:6b:1b:8c:ed brd ff:ff:ff:ff:ff:ff > 6: br-065bfd282d7c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue state UP group default > link/ether 02:42:26:5e:4a:03 brd ff:ff:ff:ff:ff:ff > inet 172.28.0.1/16 brd 172.28.255.255 scope global br-065bfd282d7c > valid_lft forever preferred_lft forever > inet6 fe80::42:26ff:fe5e:4a03/64 scope link > valid_lft forever preferred_lft forever > 7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > state DOWN group default > link/ether 02:42:2d:8f:ca:2f brd ff:ff:ff:ff:ff:ff > inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 > valid_lft forever preferred_lft forever > 9: veth06d724e@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-065bfd282d7c state UP group default > link/ether c6:fe:7f:c2:10:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 0 > inet6 fe80::c4fe:7fff:fec2:10a3/64 scope link > valid_lft forever preferred_lft forever > 11: vethb7a6f3b@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-065bfd282d7c state UP group default > link/ether 32:ad:77:18:09:6b brd ff:ff:ff:ff:ff:ff link-netnsid 1 > inet6 fe80::30ad:77ff:fe18:96b/64 scope link > valid_lft forever preferred_lft forever > 13: veth32e8e1e@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-065bfd282d7c state UP group default > link/ether 0e:18:50:70:d0:89 brd ff:ff:ff:ff:ff:ff link-netnsid 2 > inet6 fe80::c18:50ff:fe70:d089/64 scope link > valid_lft forever preferred_lft forever > 15: veth28b1f09@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-065bfd282d7c state UP group default > link/ether fe:68:30:3e:d9:b1 brd ff:ff:ff:ff:ff:ff link-netnsid 3 > inet6 fe80::fc68:30ff:fe3e:d9b1/64 scope link > valid_lft forever preferred_lft forever > 17: veth3485d29@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-065bfd282d7c state UP group default > link/ether da:c4:3c:52:d4:aa brd ff:ff:ff:ff:ff:ff link-netnsid 4 > inet6 fe80::d8c4:3cff:fe52:d4aa/64 scope link > valid_lft forever preferred_lft forever > 19: veth0495409@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-065bfd282d7c state UP group default > link/ether be:85:b9:27:af:50 brd ff:ff:ff:ff:ff:ff link-netnsid 5 > inet6 fe80::bc85:b9ff:fe27:af50/64 scope link > valid_lft forever preferred_lft forever > > ========================= > > No. Time Source Destination > Protocol Length Info > 1 0.000000000 10.100.100.188 224.0.1.129 > PTPv2 86 Sync Message > > Frame 1: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on > interface 0 > Ethernet II, Src: SuperMic_1b:8b:c0 (ac:1f:6b:1b:8b:c0), Dst: > IPv4mcast_01:81 (01:00:5e:00:01:81) > Internet Protocol Version 4, Src: 10.100.100.188, Dst: 224.0.1.129 > User Datagram Protocol, Src Port: 319, Dst Port: 319 > Source Port: 319 > Destination Port: 319 > Length: 52 > Checksum: 0x0764 [unverified] > [Checksum Status: Unverified] > [Stream index: 0] > Precision Time Protocol (IEEE1588) > 0000 .... = transportSpecific: 0x0 > .... 0000 = messageId: Sync Message (0x0) > .... 0010 = versionPTP: 2 > messageLength: 44 > subdomainNumber: 0 > flags: 0x0200 > correction: 0.000000 nanoseconds > ClockIdentity: 0xac1f6bfffe1b8bc0 > SourcePortID: 1 > sequenceId: 216 > control: Sync Message (0) > logMessagePeriod: 0 > originTimestamp (seconds): 0 > originTimestamp (nanoseconds): 0 > > No. Time Source Destination > Protocol Length Info > 2 0.000029588 10.100.100.188 224.0.1.129 > PTPv2 86 Follow_Up Message > > Frame 2: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on > interface 0 > Ethernet II, Src: SuperMic_1b:8b:c0 (ac:1f:6b:1b:8b:c0), Dst: > IPv4mcast_01:81 (01:00:5e:00:01:81) > Internet Protocol Version 4, Src: 10.100.100.188, Dst: 224.0.1.129 > User Datagram Protocol, Src Port: 320, Dst Port: 320 > Source Port: 320 > Destination Port: 320 > Length: 52 > Checksum: 0x2c63 [unverified] > [Checksum Status: Unverified] > [Stream index: 1] > Precision Time Protocol (IEEE1588) > 0000 .... = transportSpecific: 0x0 > .... 1000 = messageId: Follow_Up Message (0x8) > .... 0010 = versionPTP: 2 > messageLength: 44 > subdomainNumber: 0 > flags: 0x0000 > correction: 0.000000 nanoseconds > ClockIdentity: 0xac1f6bfffe1b8bc0 > SourcePortID: 1 > sequenceId: 216 > control: Follow_Up Message (2) > logMessagePeriod: 0 > preciseOriginTimestamp (seconds): 1552671081 > preciseOriginTimestamp (nanoseconds): 604860668 _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
