Я отлаживаю встроенную платформу Linux, у которой есть интерфейс, в котором обычные фреймы Ethernet имеют дополнительный 82-октетный заголовок платформы, прикрепленный спереди. Я могу обнюхивать этот интерфейс с помощью tcpdump, но tcpdump не может эффективно декодировать, потому что заголовки Ethernet не запускаются там, где они ожидают. Таким образом, все, что я вижу, это шестнадцатеричный дамп с параметром -x, но для удобства я хотел бы, чтобы tcpdump декодировал их. Меня не интересует содержимое 82-октетного заголовка, но я хотел бы увидеть декодирование последующего инкапсулированного кадра Ethernet.
Есть ли способ указать tcpdump начать декодирование заголовка Ethernet, начиная с 82 октета смещения от начала захваченного пакета, а не с обычных 0 октетов?
Не что иное, как изменение источника tcpdump.
Если вы хотите это сделать, я бы предложил либо использовать одно из значений DLT_USERn DLT_ / LINKTYPE_ для этого устройства, либо получить одно, официально назначенное tcpdump.org, взломать libpcap, чтобы вернуть это значение DLT_ для этих устройств, и взломать tcpdump для декодировать это, пропуская (или декодируя, если это полезно) 82-октетный заголовок платформы.
Я снова столкнулся с этим, забыв, что задал этот вопрос, но Google вернул меня сюда :).
Я нашел обходной путь для этого, если у вас есть editcap (из wirehark) доступный. Никаких изменений исходного кода не требуется:
tcpdump -i eth0 -w - | editcap -C 82 - - | tcpdump -r -
Первый вызов tcpdump захватывает пакеты и выгружает их в формате pcap в канал. editcap затем отрезает 82 байта от начала каждого пакета в потоке пакетов pcap. Затем последний вызов tcpdump считывает поток пакетов pcap и анализирует его как обычно.
Обратите внимание, что каналы вызывают значительную буферизацию, поэтому вывод не обязательно происходит немедленно. tcpdump имеет -l вариант строчной буферизации, но даже с stdbuf -i0 -o0 Мне не удалось полностью удалить буферизацию. YMMV.