PREENCHIMENTO ETHERNET, EM RESUMO
Por que uma mensagem curta pode aparecer como um quadro mais longo?
A Ethernet pode adicionar preenchimento antes do FCS para atender ao formato mínimo de quadro MAC. O preenchimento está fora de um pacote IPv4 e não deve se tornar dados da aplicação. O software de captura pode observar o processamento antes do preenchimento ou receber um registro sem o FCS, portanto seu comprimento exibido sozinho não prova uma transmissão abaixo do tamanho mínimo. Verifique o ponto de observação e a convenção de comprimento.
Construir o quadro externo
O preenchimento atende ao formato externo; ele não adiciona significado à aplicação.
Localizar o observador
O software pode ver um estágio diferente do enlace físico.
Respeitar o limite interno
Para IPv4, use o comprimento total do IP em vez de tratar o preenchimento como dados.
Verificar a contagem
Indique quais cabeçalhos, tags e bytes de FCS o comprimento inclui.
Verificar a captura
Registre a direção, os offloads, o comprimento retido e as configurações de FCS.
Verificar o analisador
Confirme que o comprimento da camada superior define o conteúdo válido da aplicação.
Lista de verificação de seleção e verificação — expandir
| Verificação | O que confirmar | Como verificar |
|---|---|---|
| Convenção de quadro | Cabeçalhos, tags e FCS | Documente o início e o fim exatos da contagem. |
| Ponto de observação | Antes da NIC, do cabo ou do receptor | Preserve as configurações de interface e de coleta. |
| Integridade da captura | Comprimento original versus comprimento retido | Verifique o truncamento e os limites de coleta. |
| Limite de protocolo | IP válido ou outro comprimento de protocolo | Inspecione o comprimento especificado e o comportamento do analisador. |
| Evidência de falha | Contadores, direção e tempo | Correlacione o tráfego conhecido em ambas as extremidades. |
Exemplos conceituais, fora de escala, não são medições nem afirmações sobre a implementação de um produto específico.
Um PLC envia uma mensagem de status curta, mas o conteúdo transmitido pela Ethernet é mais longo. Uma captura mostra 60 bytes, enquanto a documentação descreve um quadro mínimo de 64 bytes. Não conclua imediatamente que um switch removeu quatro bytes. A mensagem da aplicação, o encapsulamento Ethernet e a captura por software são camadas de observação diferentes. Colocar o preenchimento no lugar correto explica a aparente contradição.
Separar a mensagem, o pacote IP e o quadro Ethernet
Uma aplicação se importa com um status, comando ou medição, mas a transmissão precisa de informações que os equipamentos de rede possam reconhecer. Pense na mensagem como um bilhete, no pacote IP como seu envelope e no quadro Ethernet como a embalagem externa para este enlace. A analogia explica as camadas, não três caixas físicas: o cabo transporta uma sequência contínua de bits.
No exemplo comum de Ethernet sem tags usado aqui, o quadro MAC vai do endereço de destino até a sequência de verificação de quadro, ou FCS. Um endereço MAC identifica um remetente ou destinatário no enlace; o FCS ajuda o receptor a verificar erros de transmissão. O preâmbulo precede o quadro, e o intervalo entre quadros é o tempo ocioso entre transmissões. Nenhum dos dois faz parte desta contagem de 64 bytes.
O mínimo se aplica ao quadro MAC externo, não ao comprimento de cada instrução do PLC. Ao ler documentação ou capturas, primeiro estabeleça onde a contagem começa e termina. Misturar dados da aplicação, cabeçalhos e o FCS pode fazer o encapsulamento comum parecer conteúdo extra da aplicação.
Acrescentar preenchimento antes de formar a sequência de verificação de quadro
Se o conteúdo da camada superior fornecido for curto demais, o processamento de transmissão Ethernet acrescenta preenchimento após esse conteúdo e antes do FCS. É como uma embalagem protetora: ocupa espaço sem acrescentar palavras ao bilhete. Se o software, um driver ou o hardware executa uma operação específica depende da interface de rede ou da implementação embarcada.
Considere um exemplo deliberadamente delimitado: um cabeçalho Ethernet sem tags de 14 bytes transporta um pacote IPv4 de 28 bytes. Esse pacote de IP bytes pode consistir em um cabeçalho IPv4 comum e um cabeçalho UDP, sem payload de aplicação UDP. Adicionar 18 bytes de preenchimento e um FCS de quatro bytes produz um quadro MAC de 64 bytes. Isso ilustra a estrutura; não é uma medição de um dispositivo FCTEL.
O preenchimento (padding) está incluído no conteúdo protegido pelo checksum Ethernet. Ele não pode ser alterado arbitrariamente depois que o FCS é formado. O receptor verifica o quadro recebido, não apenas a mensagem da aplicação. Nenhum cálculo de CRC é necessário para entender a sequência: formar o conteúdo de quadro exigido e, em seguida, gerar seu valor de verificação correspondente.
O preenchimento não deve se tornar dados adicionais da aplicação
Para IPv4, o campo de comprimento total no cabeçalho IP define o comprimento do pacote IP, incluindo seu cabeçalho e dados, mas excluindo o preenchimento Ethernet externo. O receptor encaminha a porção IP para cima para interpretação adicional. A RFC 894 separa explicitamente o preenchimento do pacote IP e especifica preenchimento com bytes zero quando necessário para a encapsulação que descreve.
Um analisador de camada superior não deve tratar todos os bytes Ethernet capturados restantes como conteúdo da aplicação. Ele deve validar o comprimento e os limites do seu protocolo em vez de anexar o empacotamento externo a um comando. Também não deve simplesmente excluir todos os zeros finais: zero pode ser um dado válido. O protocolo, e não a aparência visual de um byte, determina o limite.
Outros protocolos de camada dois precisam de suas próprias regras de encapsulação; o comprimento total do IPv4 não pode ser aplicado mecanicamente a todos os protocolos. O preenchimento não deve carregar instruções de controle privadas ou memória não inicializada. O hábito prático é verificar separadamente o limite do quadro externo e o limite da mensagem interna.
Por que o software pode exibir 60 bytes ou até menos
O software de captura não necessariamente recebe a representação completa do fio. Muitas interfaces verificam o FCS recebido sem entregar esses quatro bytes ao sistema operacional. O software pode, portanto, registrar 60 bytes correspondentes a um quadro MAC completo de 64 bytes no fio. A documentação do Wireshark destaca essa distinção: um comprimento exibido de apenas 60 não estabelece uma transmissão abaixo do tamanho mínimo.
Uma captura no lado da transmissão pode observar outro ponto, antes que o hardware adicione o preenchimento e o FCS. Seu registro pode ser mais curto que 60 bytes, embora o hardware subsequentemente produza um quadro transmitido válido. Uma tela do remetente, uma tela do receptor e a observação do enlace físico são pontos de vista diferentes. Comparar apenas dois comprimentos exibidos não pode provar que o equipamento entre eles removeu conteúdo.
Também distinga o comprimento original do comprimento capturado. Um coletor pode reter apenas o início de cada quadro, de modo que nem todo byte original é necessariamente salvo. Verifique as configurações de captura, a entrega do FCS, a direção e o comportamento de offload, depois compare as evidências dos pares. Provar a representação física no fio exige um método de teste adequado com condições de aquisição declaradas.
O processamento de VLAN não implica uma contagem fixa de preenchimento
Os bytes de preenchimento de 18 pertencem apenas ao exemplo anterior. Diferentes comprimentos de conteúdo, marcação (tagging) e processamento de encapsulação alteram a quantidade necessária. Uma tag VLAN ocupa parte da região do cabeçalho; não a conte duas vezes quando ela já estiver incluída. Tamanho mínimo de quadro e unidade máxima de transmissão, ou MTU, também são conceitos diferentes.
Um switch recebe quadros, identifica os destinos de encaminhamento e forma a saída apropriada no próximo enlace. Equipamentos que adicionam ou removem tags devem manter os requisitos de saída. O documento de solução de problemas da Cisco referenciado ilustra um caso específico de plataforma em que remover uma tag exige preenchimento novamente. Ele ajuda a explicar um limite de processamento, não uma implementação interna universal para todos os switches.
O preenchimento normal de uma mensagem curta completa não é uma falha. Um quadro realmente abaixo do tamanho mínimo, uma transmissão anormal causada por um enlace danificado e um registro de captura encurtado durante a coleta exigem investigações diferentes. Os nomes e as condições dos contadores de porta variam conforme o equipamento. Correlacionar contadores com horários e direções de captura é mais útil do que substituir um switch apenas porque um registro parece curto.
Aplique a distinção a uma conexão de switch industrial
A página publicada do switch Fast Ethernet de cinco portas com mini trilho DIN FCTEL lista cinco portas elétricas Ethernet e adaptação 10/100M. Isso fornece uma base real de produto para um cenário de conexão de PLC e IHM. Não estabelece recursos de captura, espelhamento de porta, controle especial de preenchimento ou limites de erro específicos. Verifique a configuração selecionada em sua própria documentação.
Se um terminal envia repetidamente mensagens de status curtas enquanto outro transfere um arquivo maior, as contagens de bytes da aplicação por si só não descrevem a carga da porta. Cada quadro também consome oportunidades de encapsulação e transmissão, incluindo o espaçamento necessário. Muitas mensagens pequenas podem consumir recursos de processamento e de enlace. Comece com observações de taxa de quadros, tráfego real e ciclo da aplicação em vez de exigir fórmulas complexas.
Se uma aplicação transportada de forma transparente parecer ganhar bytes finais, primeiro verifique os limites do protocolo e o analisador. Compare o que a origem, qualquer conversor e o destino observam. Não trate automaticamente o preenchimento Ethernet como parte de uma mensagem serial, nem altere modos de equipamento apenas para eliminar o preenchimento. Estabeleça primeiro a camada afetada.
Use três perguntas para delimitar uma investigação de campo
Primeiro, identifique o ponto de observação: antes da transmissão pela origem, após a recepção pelo par ou uma cópia fornecida por um switch. Segundo, documente a convenção de comprimento: cabeçalhos incluídos, disponibilidade do FCS e se um quadro completo foi retido. Terceiro, correlacione comprimentos de protocolo, carga útil e contadores de erro para o mesmo tráfego da aplicação. Uma única captura de tela mostrando 60 bytes é insuficiente.
Para comparação, use uma mensagem curta conhecida em um ambiente de teste isolado ou em uma janela de manutenção aprovada. Preserve as capturas originais e os parâmetros de aquisição de ambas as extremidades. Confirme que a aplicação extrai apenas seu conteúdo válido e que as comunicações normais continuam. Esse teste valida aquela configuração e aquele caminho; uma exibição de ferramenta não define todas as interfaces e switches.
Por fim, observe se a anomalia acompanha uma porta, um cabo ou um método de captura. Retenha evidências brutas em vez de apenas capturas de tela anotadas. O princípio é simples: o quadro externo tem um formato mínimo, a aplicação interna tem seu próprio limite de comprimento e o software de captura registra uma etapa do processamento. Manter esses três aspectos separados ajuda a localizar uma falha real.
Fontes e evidências de produto
Wireshark: Ethernet; IETF RFC 894, abril de 1984; Documento de solução de problemas de preenchimento da Cisco, atualizado em julho de 16, 2021. Mecanismos gerais não transferem comandos específicos de plataforma nem conclusões sobre defeitos para outros equipamentos. Evidência de produto: Switch Fast Ethernet de cinco portas mini para trilho DIN FCTEL, página em chinês. Verifique a versão selecionada. As ilustrações são conceitos genéricos feitos com assistência de IA.
Traduzido do artigo técnico chinês: Leia o artigo original em chinês.
Perguntas práticas comuns
Uma captura de 60 bytes é um quadro curto inválido?
Não necessariamente. Uma captura comum omite o FCS de quatro bytes. Verifique o ponto de observação, o comprimento original e o comprimento capturado.
O preenchimento se torna um novo comando do PLC?
Não deveria. Um analisador deve usar o comprimento do protocolo de camada superior em vez de tratar o preenchimento externo como dados adicionais da aplicação.
Toda mensagem curta precisa de bytes de preenchimento 18?
Não. Dezoito bytes se aplicam apenas ao exemplo sem tag neste artigo; o conteúdo original e a encapsulação determinam o preenchimento real.
Escopo e leitura adicional
Conceitos genéricos de preenchimento Ethernet e captura, não medições nem comportamento garantido específico de modelo.
Guia relacionado sobre CRC e FCS · Guia relacionado sobre preâmbulo e intervalo entre quadros
