☰

Широковещательный кадр с неизвестным Ethertype

tag-icon • tag-icon networking ethernet
Широковещательный кадр с неизвестным Ethertype

На моей системе Linux я захватил этот кадр Ethernet:
Он состоит из 62 байтов:

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

Есть идеи, что такое Ethertype "00 54"?

Вот что я получаю с помощью tcpdump:

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

решение1

Это не Ethertype.

Кадры Ethernet могут иметь несколькоразные форматы заголовков– «Ethernet II», он же «DIX», является наиболее распространённым, но это не то, что изначально было указано в стандарте IEEE 802.

В стандартеФормат 802.2(также известный как «LLC»), за MAC-адресами следует 2-байтовыйдлина кадраполе, за которым следует 3-байтовый заголовок LLC, содержащий два значения «SAP» (обычно идентичные), указывающие номер протокола, назначенный IEEE.

(Эти два формата легко различить — «Ethertype» Ethernet II всегда больше 0x0600, тогда как «длина кадра» 802.2 всегда меньше 0x0600.)

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

В этом случае вы смотрите на кадр с SSAP=0xE0, DSAP=0xE0, что указывает на NovellNetWare IPX. Данные пакета начинаются с FF FF ..., что также соответствует обычному формату пакета NetWare IPX.

Обновлять

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

Согласно выводу tcpdump, это действительно IPX, и пакет отправляется на сокет 0x0455, который принадлежит Microsoft.NetBIOSи не к какому-либо протоколу NetWare. (Номера сокетов IPX похожи на номера портов UDP.)

NetBIOS через IPX работает точно так же, как NetBIOS через TCP/IPv4 — он обрабатывает поиск имени хоста, обрабатывает обнаружение «Сетевого окружения» / «Моих сетевых компьютеров» и, что самое важное, он поддерживает SMBv1 — старый протокол общего доступа к файлам и принтерам Windows.

Я не знаю об этом конкретном пакете, но WORKGROUPза ним обычно следует 0x1E, что означает «Выборы службы браузера» — опять же, это просто часть всего процесса обнаружения компьютеров в локальной сети. (Если бы он был отправлен по UDP/IP, это был бы совершенно обычный пакет, который можно увидеть каждый день в локальных сетях Windows.)

Я бы рекомендовал использовать tcpdump -uw mypackets.pcapи открывать захваченный файл .pcap в Wireshark, который может полностью декодировать все эти протоколы.

Я бы также рекомендовал отключить IPX на устройстве. (И пока вы этим занимаетесь, проверьте, включен ли на устройстве AppleTalk — отключите и его.)

Связанный контент