☰

El uso de PTP en un conmutador estilo DSA hace que los paquetes parezcan distorsionados

tag-icon • tag-icon linux network-interface ip bridge
El uso de PTP en un conmutador estilo DSA hace que los paquetes parezcan distorsionados

Entonces tengo una placa SoC Altera Cyclone V que ejecuta Linux 5.7.10 y contiene un conmutador BCM53125 rev4, tres puertos LAN y un puerto de CPU (la NIC). La arquitectura de conmutador distribuido está en uso, por lo que mi configuración tiene el siguiente aspecto:

                 ------- lan1
                 |
eth0 (CPU) --- Switch -- lan2
                 |
                 ------- lan3

Quiero ejecutar PTP con marca de tiempo de hardware en esta máquina. Ahora, ethtool muestra solo las capacidades correctas de eth0 (probadas usando ethtool -T eth0), es decir,

# ethtool -T eth0
Time stamping parameters for eth0:
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)
        ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
        ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
        ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
        ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
        ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
        ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
        ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
        ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

Falla para lan1 y amigos:

# ethtool -T lan1
Time stamping parameters for lan1:
Cannot get device time stamping settings: Operation not supported

Entonces, mi pregunta es, ¿cómo puedo usar eth0 y sus capacidades de comunicación?

Intenté configurar un puente y, alternativamente, direcciones IP para cada puerto LAN como se describeaquí. Luego inicio un maestro PTP en la placa usando eth0 como interfaz de red:

# ./ptp4l -qmi eth0
ptp4l[3658.796]: selected /dev/ptp0 as PTP clock
ptp4l[3658.807]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[3658.807]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[3666.525]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[3666.525]: selected local clock 664975.fffe.e52d47 as best master
ptp4l[3666.525]: port 1: assuming the grand master role

No se reportaron problemas. Sin embargo, si capturo algunos paquetes usando Wireshark, esos paquetes no se parecen en nada a PTP:

Salida extraña que muestra paquetes extraños

No solo eso, también carecen de un EtherType (como 0x8000 para IP) en el encabezado de Ethernet, sino que tienen valores como 0x0048 o 0x005c que, cuando se interpretan como longitud de carga útil de acuerdo con IEEE 802.3, ni siquiera coinciden con la longitud real. longitud de la carga útil. Aquí hay una descripción detallada del primer paquete en la imagen de arriba:

Detalles del primer paquete que elabora lo anterior.

Aquí también hay un volcado hexadecimal, para obtener toda la gama de detalles:

01 00 5e 00 01 81 66 49 75 e5 2d 47 00 5c 02 48
40 00 01 11 8a 4d 0a 00 01 7b e0 00 01 81 01 40
01 40 00 48 06 d3 0b 02 00 40 00 00 00 08 00 00
00 00 00 00 00 00 00 00 00 00 66 49 75 ff fe e5
2d 47 00 01 00 00 05 01 00 00 00 00 00 00 00 00
00 00 00 25 00 80 f8 fe ff ff 80 66 49 75 ff fe
e5 2d 47 00 00 a0

Entonces, justo en la capa de enlace, las cosas ya van mal por alguna razón. Supongo que tiene que ver con que conecté el maestro PTP al puerto de la CPU, algo que el subsistema DSA de alguna manera no puede manejar/no espera.

Entonces me gustaría saber

  1. si este es el camino a seguir para conectarse directamente a eth0, no a un puerto LAN y
  2. por qué los paquetes están tan estropeados.

Quiero, en cierto modo, eludir DSA. Resulta que estoy atascado con eso, pero un puerto con capacidades de marca de tiempo sería suficiente para mis propósitos.

Respuesta1

Esos conjuntos de chips Broadcom a menudo no son verdaderos conmutadores y, a menudo, todos los puertos Ethernet no son puertos completos per se.

El BCM53125 parece mejor que los habituales en placas más baratas en ese sentido, pero aun así, es posible que ambos no estén lidiando con todas las capacidades de un conmutador comercial y puertos Ethernet completos.

El soporte PTP tampoco parece verse por ninguna parte en el cambiohojas de datos, extraña herramienta étnica que lo muestra (puede que se me haya escapado)

Mi sospecha es que quizás se espere demasiado de conjuntos de chips tan humildes.

información relacionada