ETHERNET-PADDING AUF EINEN BLICK
Warum kann eine kurze Nachricht als längeres Frame erscheinen?
Ethernet kann vor dem FCS Padding hinzufügen, um das Mindestformat des MAC-Frames zu erfüllen. Das Padding liegt außerhalb eines IPv4-Pakets und sollte nicht zu Anwendungsdaten werden. Capture-Software kann die Verarbeitung vor dem Padding beobachten oder einen Datensatz ohne das FCS empfangen, sodass ihre allein angezeigte Länge keine zu kurze Übertragung beweist. Prüfen Sie den Beobachtungspunkt und die Längenkonvention.
Das äußere Frame aufbauen
Padding erfüllt das äußere Format; es fügt keine Anwendungsbedeutung hinzu.
Den Beobachter lokalisieren
Software kann eine andere Stufe als die physische Verbindung sehen.
Die innere Grenze beachten
Verwenden Sie für IPv4 die Gesamtlänge aus IP, statt Padding als Daten zu behandeln.
Die Zählung prüfen
Geben Sie an, welche Header, Tags und FCS-Bytes die Länge umfasst.
Die Aufzeichnung prüfen
Erfassen Sie Richtung, Offloads, beibehaltene Länge und FCS-Einstellungen.
Den Parser prüfen
Bestätigen Sie, dass die Länge der oberen Schicht den gültigen Anwendungsinhalt definiert.
Checkliste für Auswahl und Verifikation — erweitern
| Prüfung | Was zu bestätigen ist | Wie zu überprüfen ist |
|---|---|---|
| Frame-Konvention | Header, Tags und FCS | Dokumentieren Sie den genauen Anfang und das Ende der Zählung. |
| Beobachtungspunkt | Vor NIC, Leitung oder Empfänger | Behalten Sie Schnittstellen- und Erfassungseinstellungen bei. |
| Vollständigkeit der Aufzeichnung | Originallänge gegenüber beibehaltener Länge | Prüfen Sie Kürzung und Erfassungsgrenzen. |
| Protokollgrenze | Gültige IP oder andere Protokolllänge | Untersuchen Sie die angegebene Länge und das Parser-Verhalten. |
| Fehlernachweis | Zähler, Richtung und Zeit | Korrelieren Sie bekannten Datenverkehr an beiden Enden. |
Konzeptionelle Beispiele, nicht maßstabsgetreu, keine Messungen oder Aussagen über die Implementierung eines bestimmten Produkts.
Eine SPS sendet eine kurze Statusnachricht, doch der über Ethernet übertragene Inhalt ist länger. Eine Aufzeichnung zeigt 60 Bytes, während die Dokumentation ein Mindestframe von 64 Bytes beschreibt. Ziehen Sie nicht sofort den Schluss, dass ein Switch vier Bytes entfernt hat. Die Anwendungsnachricht, die Ethernet-Kapselung und die Software-Aufzeichnung sind unterschiedliche Beobachtungsebenen. Das Padding an der richtigen Stelle erklärt den scheinbaren Widerspruch.
Nachricht, IP-Paket und Ethernet-Frame trennen
Eine Anwendung interessiert sich für einen Status, einen Befehl oder eine Messung, doch die Übertragung benötigt Informationen, die Netzwerkgeräte erkennen können. Stellen Sie sich die Nachricht als Notiz, das IP-Paket als ihren Umschlag und das Ethernet-Frame als äußere Verpackung für diese Verbindung vor. Die Analogie erklärt Schichten, nicht drei physische Boxen: Die Leitung überträgt eine kontinuierliche Bitfolge.
Im hier verwendeten gewöhnlichen ungetaggten Ethernet-Beispiel reicht das MAC-Frame von der Zieladresse bis zur Frame Check Sequence, also FCS. Eine MAC-Adresse identifiziert einen Sender oder Empfänger auf der Verbindung; die FCS hilft einem Empfänger, Übertragungsfehler zu erkennen. Die Präambel geht dem Frame voraus, und der Interframe-Abstand ist Leerlaufzeit zwischen Übertragungen. Beide sind nicht Teil dieser Zählung von 64 Bytes.
Das Minimum gilt für das äußere MAC-Frame, nicht für die Länge jeder SPS-Anweisung. Stellen Sie beim Lesen von Dokumentation oder Aufzeichnungen zuerst fest, wo die Zählung beginnt und endet. Das Vermischen von Anwendungsdaten, Headern und dem FCS kann gewöhnliche Kapselung wie zusätzlichen Anwendungsinhalt aussehen lassen.
Padding vor dem Bilden der Frame Check Sequence anhängen
Wenn der bereitgestellte Inhalt der oberen Schicht zu kurz ist, hängt die Ethernet-Sendeverarbeitung Padding nach diesem Inhalt und vor dem FCS an. Es ist wie Schutzverpackung: Sie nimmt Platz ein, ohne der Notiz Wörter hinzuzufügen. Ob Software, ein Treiber oder Hardware einen bestimmten Vorgang ausführt, hängt von der Netzwerkschnittstelle oder der eingebetteten Implementierung ab.
Betrachten Sie ein bewusst begrenztes Beispiel: Ein ungetaggter Ethernet-Header von 14 Bytes trägt ein IPv4-Paket von 28 Bytes. Dieses IP-Paket kann aus einem gewöhnlichen IPv4-Header und einem UDP-Header ohne UDP-Anwendungsnutzlast bestehen. Das Hinzufügen von 18 Padding-Bytes und einer vier Byte großen FCS ergibt ein MAC-Frame von 64 Bytes. Dies veranschaulicht die Struktur; es ist keine Messung eines FCTEL-Geräts.
Die Auffüllung ist Teil des durch die Ethernet-Prüfsumme geschützten Inhalts. Sie kann nach der Bildung von FCS nicht beliebig geändert werden. Der Empfänger prüft das empfangene Frame, nicht nur die Anwendungsnachricht. Zur Nachvollziehung der Reihenfolge ist keine CRC-Berechnung erforderlich: den erforderlichen Frame-Inhalt bilden, dann den zugehörigen Prüfwert erzeugen.
Auffüllung sollte nicht zu zusätzlichen Anwendungsdaten werden
Bei IPv4 definiert das Gesamtlängenfeld im IP-Header die Paketlänge von IP, einschließlich Header und Daten, aber ohne äußere Ethernet-Auffüllung. Der Empfänger reicht den IP-Anteil zur weiteren Interpretation nach oben weiter. RFC 894 trennt die Auffüllung ausdrücklich vom IP-Paket und legt Nullbyte-Auffüllung fest, wenn sie für die beschriebene Kapselung erforderlich ist.
Ein Parser der oberen Schicht darf nicht alle verbleibenden erfassten Ethernet-Bytes als Anwendungsinhalt behandeln. Er sollte seine Protokolllänge und Grenzen validieren, statt die äußere Auffüllung an einen Befehl anzuhängen. Ebenso wenig sollte er einfach jedes abschließende Nullbyte löschen: Null kann gültige Daten sein. Das Protokoll, nicht das visuelle Erscheinungsbild eines Bytes, bestimmt die Grenze.
Andere Layer-2-Protokolle benötigen eigene Kapselungsregeln; die Gesamtlänge von IPv4 lässt sich nicht mechanisch auf jedes Protokoll anwenden. Auffüllung sollte keine privaten Steueranweisungen oder nicht initialisierten Speicher enthalten. Die praktische Gewohnheit ist, die äußere Frame-Grenze und die innere Nachrichtengrenze getrennt zu prüfen.
Warum Software möglicherweise 60 Bytes oder sogar weniger anzeigt
Erfassungssoftware erhält nicht zwangsläufig die vollständige Darstellung auf dem Draht. Viele Schnittstellen prüfen das eingehende FCS, ohne diese vier Bytes an das Betriebssystem weiterzugeben. Software kann daher 60 Bytes aufzeichnen, die einem vollständigen 64-Byte-MAC-Frame auf dem Draht entsprechen. Die Wireshark-Dokumentation hebt diesen Unterschied hervor: Eine angezeigte Länge von nur 60 belegt noch keine zu kurze Übertragung.
Eine Erfassung auf der Sendeseite kann einen anderen Punkt beobachten, bevor die Hardware Auffüllung und FCS hinzufügt. Ihr Datensatz kann kürzer als 60 Bytes sein, obwohl die Hardware anschließend ein gültiges gesendetes Frame erzeugt. Ein Senderbildschirm, ein Empfängerbildschirm und eine Beobachtung der physischen Strecke sind unterschiedliche Blickwinkel. Ein bloßer Vergleich zweier angezeigter Längen kann nicht beweisen, dass Geräte dazwischen Inhalte entfernt haben.
Unterscheiden Sie außerdem die Originallänge von der erfassten Länge. Ein Sammler kann nur den Anfang jedes Frames behalten, sodass nicht jedes Originalbyte zwangsläufig gespeichert wird. Prüfen Sie Erfassungseinstellungen, FCS-Übergabe, Richtung und Offload-Verhalten und vergleichen Sie dann die Belege der Gegenstelle. Der Nachweis der physischen Darstellung auf dem Draht erfordert eine geeignete Testmethode mit angegebenen Erfassungsbedingungen.
VLAN-Verarbeitung bedeutet nicht eine feste Anzahl an Auffüllbytes
Die Auffüllbytes von 18 gehören nur zum vorangehenden Beispiel. Unterschiedliche Inhaltslängen, Tagging und Kapselungsverarbeitung ändern die benötigte Menge. Ein VLAN-Tag belegt einen Teil des Header-Bereichs; zählen Sie ihn nicht doppelt, wenn er bereits enthalten ist. Minimale Frame-Größe und maximale Übertragungseinheit (MTU) sind ebenfalls unterschiedliche Konzepte.
Ein Switch empfängt Frames, ermittelt Weiterleitungsziele und bildet die passende Ausgabe auf der nächsten Strecke. Geräte, die Tags hinzufügen oder entfernen, müssen die Ausgabeanforderungen einhalten. Das referenzierte Cisco-Fehlerbehebungsdokument veranschaulicht einen spezifischen Plattformfall, in dem das Entfernen eines Tags erneute Auffüllung erfordert. Es hilft, eine Verarbeitungsgrenze zu erklären, nicht eine universelle interne Implementierung für jeden Switch.
Normale Auffüllung einer vollständigen kurzen Nachricht ist kein Fehler. Ein tatsächlich zu kurzes Frame, eine durch eine beschädigte Strecke verursachte anormale Übertragung und ein während der Erfassung verkürzter Datensatz erfordern unterschiedliche Untersuchungen. Namen und Bedingungen von Portzählern variieren je nach Gerät. Zähler mit Erfassungszeiten und -richtungen zu korrelieren ist nützlicher, als einen Switch nur wegen eines kurz aussehenden Datensatzes zu ersetzen.
Die Unterscheidung auf eine industrielle Switch-Verbindung anwenden
Die veröffentlichte Seite zum FCTEL Mini-DIN-Schienen-Fast-Ethernet-Switch mit fünf Ports listet fünf elektrische Ethernet-Ports und 10/100M-Anpassung auf. Dies bietet eine reale Produktgrundlage für ein Szenario mit PLC- und HMI-Verbindung. Es belegt keine Erfassungsfunktionen, Portspiegelung, spezielle Auffüllungssteuerung oder bestimmte Fehlerschwellen. Prüfen Sie die gewählte Konfiguration anhand ihrer eigenen Dokumentation.
Wenn ein Endgerät wiederholt kurze Statusmeldungen sendet, während ein anderes eine größere Datei überträgt, beschreiben Anwendungs-Byte-Zahlen allein nicht die Portlast. Jedes Frame verbraucht auch Kapselungs- und Übertragungsmöglichkeiten, einschließlich des erforderlichen Abstands. Viele kleine Nachrichten können Verarbeitungs- und Streckenressourcen beanspruchen. Beginnen Sie mit Beobachtungen von Frame-Rate, tatsächlichem Verkehr und Anwendungszyklus, statt komplexe Formeln zu verlangen.
Wenn eine transparent übertragene Anwendung scheinbar abschließende Bytes hinzugewinnt, prüfen Sie zuerst Protokollgrenzen und den Parser. Vergleichen Sie, was die Quelle, ein etwaiger Konverter und das Ziel jeweils beobachten. Behandeln Sie Ethernet-Auffüllung nicht automatisch als Teil einer seriellen Nachricht und ändern Sie Gerätemodi nicht einfach, um Auffüllung zu beseitigen. Stellen Sie zuerst die betroffene Schicht fest.
Drei Fragen zur Eingrenzung einer Felduntersuchung
Erstens, den Beobachtungspunkt bestimmen: vor der Quellübertragung, nach dem Empfang durch die Gegenstelle oder eine von einem Switch gelieferte Kopie. Zweitens, die Längenkonvention dokumentieren: enthaltene Header, FCS-Verfügbarkeit und ob ein vollständiges Frame behalten wurde. Drittens, Protokolllängen, Nutzdaten und Fehlerzähler für denselben Anwendungsverkehr korrelieren. Ein einzelner Screenshot mit 60 Bytes reicht nicht aus.
Verwenden Sie zum Vergleich eine bekannte kurze Nachricht in einer isolierten Testumgebung oder einem genehmigten Wartungsfenster. Bewahren Sie Originalerfassungen und Erfassungsparameter von beiden Enden auf. Bestätigen Sie, dass die Anwendung nur ihren gültigen Inhalt extrahiert und die normale Kommunikation weiterläuft. Ein solcher Test validiert diese Konfiguration und diesen Pfad; eine Tool-Anzeige definiert nicht jede Schnittstelle und jeden Switch.
Beobachten Sie schließlich, ob die Anomalie einem Port, einem Kabel oder einer Erfassungsmethode folgt. Bewahren Sie Rohbelege auf, nicht nur kommentierte Screenshots. Das Prinzip ist einfach: Das äußere Frame hat ein Mindestformat, die innere Anwendung hat ihre eigene Längengrenze, und Erfassungssoftware zeichnet eine Verarbeitungsstufe auf. Diese drei getrennt zu halten hilft, einen echten Fehler zu lokalisieren.
Quellen und Produktbelege
Wireshark: Ethernet; IETF RFC 894, April 1984; Cisco-Dokument zur Fehlerbehebung bei Auffüllung, aktualisiert im Juli 16, 2021. Allgemeine Mechanismen übertragen keine plattformspezifischen Befehle oder Fehlerschlussfolgerungen auf andere Geräte. Produktbeleg: FCTEL kompakter fünfportiger Fast-Ethernet-Switch für DIN-Schienenmontage, chinesischsprachige Seite. Prüfen Sie die gewählte Version. Abbildungen sind generische Konzepte, die mit KI-Unterstützung erstellt wurden.
Übersetzt aus dem chinesischen Fachartikel: Den chinesischen Originalartikel lesen.
Häufige praktische Fragen
Ist eine Aufzeichnung von 60 Bytes ein ungültiges kurzes Frame?
Nicht unbedingt. Eine übliche Erfassung lässt die vier Bytes von FCS aus. Prüfen Sie Beobachtungspunkt, Originallänge und erfasste Länge.
Wird Padding zu einem neuen SPS-Befehl?
Sollte es nicht. Ein Parser muss die Länge des oberen Protokolls verwenden, statt äußere Auffüllung als zusätzliche Anwendungsdaten zu behandeln.
Braucht jede kurze Nachricht 18 Padding-Bytes?
Nein. Achtzehn Bytes gelten nur für das ungetaggte Beispiel in diesem Artikel; der Originalinhalt und die Kapselung bestimmen die tatsächliche Auffüllung.
Geltungsbereich und weiterführende Literatur
Allgemeine Konzepte zu Ethernet-Auffüllung und Erfassung, keine Messungen oder garantiertes modellspezifisches Verhalten.
Verwandter Leitfaden zu CRC und FCS · Verwandter Leitfaden zu Präambel und Frame-Abstand
