Usar PTP em switch estilo DSA faz com que os pacotes pareçam distorcidos

Usar PTP em switch estilo DSA faz com que os pacotes pareçam distorcidos

Portanto, tenho uma placa SoC Altera Cyclone V rodando Linux 5.7.10 contendo um switch BCM53125 rev4, três portas LAN e uma porta de CPU (a NIC). A arquitetura de switch distribuído está em uso, então minha configuração é a seguinte:

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

Quero obter PTP com carimbo de data/hora de hardware em execução nesta máquina. Agora, ethtool mostra apenas os recursos corretos do eth0 (testados usando ethtool -T eth0), ou seja,

# 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)

Falha para lan1 e amigos:

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

Então, minha pergunta é: como posso usar a eth0 e seus recursos de comunicação?

Tentei configurar uma ponte e, alternativamente, endereços IP para cada porta LAN conforme descritoaqui. Então eu inicio um mestre PTP na placa usando eth0 como interface de rede:

# ./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

Nenhum problema relatado. No entanto, se eu capturar alguns pacotes usando o Wireshark, esses pacotes não se parecerão em nada com PTP:

Saída estranha mostrando pacotes estranhos

Além disso, eles também não possuem um EtherType (como 0x8000 para IP) no cabeçalho Ethernet, mas possuem valores como 0x0048 ou 0x005c, que, quando interpretados como comprimento de carga útil de acordo com IEEE 802.3, nem sequer correspondem ao tamanho real. comprimento da carga útil. Aqui está uma descrição detalhada do primeiro pacote na imagem acima:

Detalhes do primeiro pacote elaborando o acima

Aqui está também um despejo hexadecimal, para toda a gama de detalhes:

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

Então, bem na camada de link, as coisas já dão errado por algum motivo. Meu palpite é que isso tem a ver com a conexão do mestre PTP à porta da CPU, que o subsistema DSA de alguma forma não consegue manipular/não espera.

Então, eu gostaria de saber

  1. se este for o caminho a seguir para conectar-se diretamente à eth0, não a uma porta LAN e
  2. por que os pacotes estão tão bagunçados.

Quero, de certa forma, contornar o DSA. Acontece que estou preso a isso, mas uma porta com recursos de carimbo de data e hora seria suficiente para meus propósitos.

Responder1

Esses chipsets Broadcom geralmente não são switches verdadeiros e muitas vezes nem todas as portas Ethernet são portas completas em si.

O BCM53125 parece melhor do que os habituais em placas mais baratas nesse aspecto, mas mesmo assim, vocês dois podem não estar lidando com todos os recursos de um switch comercial e portas Ethernet completas.

O suporte PTP também parece não ser visto em nenhum lugar no switchfolhas de dados, estranho ethtool mostrando isso (pode ter me escapado)

Minha suspeita é que você espera muito de chipsets tão humildes.

informação relacionada