☰

Broadcast-Frame mit unbekanntem Ethertype

tag-icon • tag-icon networking ethernet
Broadcast-Frame mit unbekanntem Ethertype

Auf meinem Linux-System habe ich diesen Ethernet-Frame erfasst:
Er besteht aus 62 Bytes:

FF FF FF FF FF FF  00 12 3F 8C BB C2  00 54  E0 E0 03 FF FF 00 50 00

Irgendeine Idee, was der Ethertyp „00 54“ ist?

Das ist, was ich mit tcpdump bekomme:

10:06:07.093666 IPX 00000000.00:12:3f:8c:bb:c2.0455 > 00000000.ff:ff:ff:ff:ff:ff.0455: ipx-netbios 50 0x0000: ffff ffff ffff 0012 3f8c bbc2 0054 e0e0 ........?....T..

    0x0010:  03ff ff00 5000 1400 0000 00ff ffff ffff  ....P...........

    0x0020:  ff04 5500 0000 0000 123f 8cbb c204 5500  ..U......?....U.

    0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................

    0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................

    0x0050:  0157 4f52 4b47 524f 5550 2020 2020 2020  .WORKGROUP......

    0x0060:  1eff                                     ..

Antwort1

Das ist kein Ethertyp.

Ethernet-Frames können einige habenverschiedene Header-Formate– „Ethernet II“ alias „DIX“ ist die gebräuchlichste Bezeichnung, entspricht aber nicht der ursprünglichen Spezifikation des IEEE-802-Standards.

Im Standard802.2-Format(auch bekannt als „LLC“), auf die MAC-Adressen folgt ein 2-ByteRahmenlängeFeld, gefolgt von einem 3-Byte-LLC-Header, der zwei (normalerweise identische) „SAP“-Werte enthält, die die vom IEEE zugewiesene Protokollnummer angeben.

(Die beiden Formate lassen sich leicht unterscheiden – ein Ethernet II-„Ethertype“ liegt immer über 0x0600, während die 802.2-„Frame-Länge“ immer unter 0x0600 liegt.)

FF FF FF FF FF FF    destination MAC
00 12 3F 8C BB C2    source MAC
00 54                frame length (84 bytes)
E0 E0 03             LLC header
├─E0                   DSAP (E0=NetWare)
├─E0                   SSAP (E0=NetWare)
└─03                   control
FF FF 00 50 00...    data

In diesem Fall sehen Sie einen Frame mit SSAP=0xE0, DSAP=0xE0, was auf Novell hinweistNetWare IPX. Die Paketdaten beginnen bei FF FF ..., was auch dem üblichen NetWare IPX-Paketformat entspricht.

Aktualisieren

10:06:07.093666 IPX 00000000.00:12:3f:8c:bb:c2.0455 > 00000000.ff:ff:ff:ff:ff:ff.0455:
ipx-netbios 50
     0x0000:  ffff ffff ffff 0012 3f8c bbc2 0054 e0e0 ........?....T..
     0x0010:  03ff ff00 5000 1400 0000 00ff ffff ffff  ....P...........
     0x0020:  ff04 5500 0000 0000 123f 8cbb c204 5500  ..U......?....U.
     0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
     0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
     0x0050:  0157 4f52 4b47 524f 5550 2020 2020 2020  .WORKGROUP......
     0x0060:  1eff

Laut Ihrer tcpdump-Ausgabe handelt es sich tatsächlich um IPX, und das Paket wird über den Socket 0x0455 gesendet, der zu Microsoft gehört.NetBIOSund nicht an irgendein NetWare-Protokoll. (IPX-Socket-Nummern sind ähnlich wie UDP-Port-Nummern.)

NetBIOS über IPX funktioniert genau wie NetBIOS über TCP/IPv4 – es übernimmt die Hostnamensuche, die Erkennung von „Netzwerkumgebung“ und „Meine Netzwerkcomputer“ und, was am wichtigsten ist, es unterstützt SMBv1 – das alte Datei- und Druckerfreigabeprotokoll von Windows.

Ich weiß nichts über dieses spezielle Paket, aber WORKGROUPgefolgt von 0x1E bedeutet normalerweise „Browser Service Elections“ – auch das ist nur ein Teil der ganzen Sache mit der LAN-Computererkennung. (Wäre es über UDP/IP gesendet worden, wäre es ein völlig normales Paket, das man jeden Tag in Windows-LANs sieht.)

Ich würde empfehlen, tcpdump -uw mypackets.pcapdie erfasste .pcap-Datei in Wireshark zu verwenden und zu öffnen, da dies alle diese Protokolle vollständig dekodieren kann.

Ich würde außerdem empfehlen, IPX auf dem Gerät zu deaktivieren. (Und wenn Sie schon dabei sind, prüfen Sie, ob AppleTalk auf dem Gerät aktiviert ist – deaktivieren Sie das ebenfalls.)

verwandte Informationen