Чем открыть формат pcap
Русские Блоги
Формат сообщения-Подробное объяснение формата файла PCAP
Даже для студентов, которые уже использовали wireshark, многие люди не особенно понимают формат сообщений pcap и значение слоя фрейма, предоставляемого в wireshark. Я считаю, что с помощью этой главы вы сможете получить эти новые знания (эта статья Один из моих столбцов «Wireshark от входа до мастера», заинтересованные могут обратить внимание).
На рисунке 1 показана принципиальная схема файловой структуры сообщения pcap: 
Рисунок 1
Структура глобального заголовка в исходном коде wireshark содержит следующие поля:
Значение каждого поля в глобальном заголовке следующее:
Структура заголовка пакета в исходном коде wireshark содержит следующие поля:
Значение каждого поля в заголовке пакета следующее:
Для получения информации в глобальном заголовке и заголовке пакета wireshark добавляет дополнительный уровень кадра для каждого пакета при отображении и анализе данных пакета. Приведенные выше данные пакета отображаются в wireshark, как показано на рисунке 3: 
Рисунок 3
Как видно из рисунка 3, информация, предоставляемая этим слоем, включает два типа, один тип не имеет квадратных скобок, этот тип информации означает, что он может быть извлечен из текста дейтаграммы pcap Немного информации.
Хотя кадр не является частью сетевого протокола, wireshark предоставляет фильтры отображения для уровня кадра, как и каждый протокол для фильтрации пакетов (выравнивание данных уровня IP, уровня TCP и уровня HTTP), как показано на рисунке 4: 
Рисунок 4
Я считаю, что благодаря вышеприведенному введению у вас должно появиться новое понимание информации, предоставляемой слоем фрейма и форматом файла pcap.
Эта статья является оригинальной статьей молодого мальчика из CSDN Village.Вот。
Расширение файла PCAP
Packet Capture Data
Что такое файл PCAP?
Что такое сниффер?
Программное приложение Wireshark
Программы, которые поддерживают PCAP расширение файла
Ниже вы найдете указатель программ, которые можно использовать для открытия файлов PCAP, разделенных на категории 2 в соответствии с поддерживаемой системной платформой. Файлы с суффиксом PCAP могут быть скопированы на любое мобильное устройство или системную платформу, но может быть невозможно открыть их должным образом в целевой системе.
Программы, обслуживающие файл PCAP
Как открыть файл PCAP?
Причин, по которым у вас возникают проблемы с открытием файлов PCAP в данной системе, может быть несколько. Что важно, все распространенные проблемы, связанные с файлами с расширением PCAP, могут решать сами пользователи. Процесс быстрый и не требует участия ИТ-специалиста. Приведенный ниже список проведет вас через процесс решения возникшей проблемы.
Шаг 1. Получить Wireshark
Проблемы с открытием и работой с файлами PCAP, скорее всего, связаны с отсутствием надлежащего программного обеспечения, совместимого с файлами PCAP на вашем компьютере. Эта проблема может быть решена путем загрузки и установки # РЕКОМЕНДОВАННОЙ # или другой совместимой программы, такой как WinDump, NetworkMiner, tcpdump. В верхней части страницы находится список всех программ, сгруппированных по поддерживаемым операционным системам. Одним из наиболее безопасных способов загрузки программного обеспечения является использование ссылок официальных дистрибьюторов. Посетите сайт Wireshark и загрузите установщик.
Шаг 2. Обновите Wireshark до последней версии
Если у вас уже установлен Wireshark в ваших системах и файлы PCAP по-прежнему не открываются должным образом, проверьте, установлена ли у вас последняя версия программного обеспечения. Разработчики программного обеспечения могут реализовать поддержку более современных форматов файлов в обновленных версиях своих продуктов. Причиной того, что Wireshark не может обрабатывать файлы с PCAP, может быть то, что программное обеспечение устарело. Все форматы файлов, которые прекрасно обрабатывались предыдущими версиями данной программы, также должны быть открыты с помощью Wireshark.
Шаг 3. Свяжите файлы Packet Capture Data с Wireshark
Если у вас установлена последняя версия Wireshark и проблема сохраняется, выберите ее в качестве программы по умолчанию, которая будет использоваться для управления PCAP на вашем устройстве. Метод довольно прост и мало меняется в разных операционных системах.
Выбор приложения первого выбора в Windows
Выбор приложения первого выбора в Mac OS
Шаг 4. Проверьте PCAP на наличие ошибок
Вы внимательно следили за шагами, перечисленными в пунктах 1-3, но проблема все еще присутствует? Вы должны проверить, является ли файл правильным PCAP файлом. Вероятно, файл поврежден и, следовательно, недоступен.
1. Проверьте PCAP файл на наличие вирусов или вредоносных программ.
Если файл заражен, вредоносная программа, находящаяся в файле PCAP, препятствует попыткам открыть его. Рекомендуется как можно скорее сканировать систему на наличие вирусов и вредоносных программ или использовать онлайн-антивирусный сканер. Если сканер обнаружил, что файл PCAP небезопасен, действуйте в соответствии с инструкциями антивирусной программы для нейтрализации угрозы.
2. Убедитесь, что структура файла PCAP не повреждена
Если файл PCAP был отправлен вам кем-то другим, попросите этого человека отправить вам файл. Возможно, файл был ошибочно скопирован, а данные потеряли целостность, что исключает доступ к файлу. При загрузке файла с расширением PCAP из Интернета может произойти ошибка, приводящая к неполному файлу. Попробуйте загрузить файл еще раз.
3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.
Существует вероятность того, что данный файл может быть доступен только пользователям с достаточными системными привилегиями. Выйдите из своей текущей учетной записи и войдите в учетную запись с достаточными правами доступа. Затем откройте файл Packet Capture Data.
4. Убедитесь, что ваше устройство соответствует требованиям для возможности открытия Wireshark
Операционные системы могут иметь достаточно свободных ресурсов для запуска приложения, поддерживающего файлы PCAP. Закройте все работающие программы и попробуйте открыть файл PCAP.
5. Проверьте, есть ли у вас последние обновления операционной системы и драйверов
Современная система и драйверы не только делают ваш компьютер более безопасным, но также могут решить проблемы с файлом Packet Capture Data. Возможно, что одно из доступных обновлений системы или драйверов может решить проблемы с файлами PCAP, влияющими на более старые версии данного программного обеспечения.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла PCAP мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле PCAP.
PCAP: захват пакетов, что это такое и что вам нужно знать
Почему мне нужно использовать PCAP?
PCAP является ценным ресурсом для анализа файлов и мониторинга сетевого трафика. Инструменты сбора пакетов, такие как Wireshark, позволяют собирать сетевой трафик и переводить его в удобочитаемый формат. Существует множество причин, по которым PCAP используется для мониторинга сетей. Некоторые из наиболее распространенных включают мониторинг использования полосы пропускания, выявление мошеннических серверов DHCP, обнаружение вредоносных программ, разрешение DNS и реагирование на инциденты..
Для сетевых администраторов и исследователей безопасности анализ файлов пакетов является хорошим способом обнаружения сетевых вторжений и других подозрительных действий. Например, если источник отправляет в сеть большое количество вредоносного трафика, вы можете определить его с помощью программного агента и затем предпринять действия для устранения атаки..
Как работает Packet Sniffer?
Для захвата файлов PCAP вам нужно использовать анализатор пакетов. Анализатор пакетов захватывает пакеты и представляет их так, чтобы их было легко понять. При использовании анализатора PCAP первое, что вам нужно сделать, это определить, какой интерфейс вы хотите прослушивать. Если вы используете устройство Linux, это может быть eth0 или wlan0. Вы можете выбрать интерфейс с команда ifconfig.
Как только вы узнаете, какой интерфейс вы хотите прослушать, вы можете выбрать, какой тип трафика вы хотите отслеживать. Например, если вы хотите отслеживать только пакеты TCP / IP, вы можете создать правила для этого. Многие инструменты предлагают фильтры, которые позволяют вам контролировать, какой трафик вы собираете.
Например, Wireshark позволяет фильтровать тип трафика, который вы видите, с помощью фильтров захвата и фильтров отображения. Фильтры захвата позволяют фильтровать трафик, который вы захватываете, а фильтры отображения позволяют фильтровать трафик, который вы видите. Например, вы можете фильтровать протоколы, потоки или хосты.
Собрав отфильтрованный трафик, вы можете начать искать проблемы с производительностью. Для более целенаправленного анализа вы также можете фильтровать на основе портов источника и портов назначения для тестирования определенных элементов сети. Вся собранная информация может затем использоваться для устранения проблем производительности сети.
Версии PCAP
Как упоминалось выше, существует множество различных типов файлов PCAP, в том числе:
Такие инструменты, как Wireshark, используют PCAPng, потому что он может записывать больше информации, чем PCAP. Однако проблема с PCAPng заключается в том, что он не совместим с таким количеством инструментов, как PCAPng..
Преимущества захвата пакетов и PCAP
Самым большим преимуществом захвата пакетов является то, что он обеспечивает видимость. Вы можете использовать пакетные данные, чтобы точно определить причину сетевых проблем. Вы можете отслеживать источники трафика и определять данные об использовании приложений и устройств. Данные PCAP предоставляют вам информацию в реальном времени, необходимую для поиска и устранения проблем с производительностью, чтобы поддерживать работу сети после события безопасности.
Например, вы можете определить, где вредоносная программа проникла в сеть, отслеживая поток вредоносного трафика и другие вредоносные сообщения. Без PCAP и инструмента захвата пакетов было бы сложнее отслеживать пакеты и управлять рисками безопасности.
Как простой формат файла, PCAP обладает тем преимуществом, что он совместим практически с любой программой, которая вам нужна, с диапазоном версий для Windows, Linux и Mac OS. Захват пакетов может быть развернут практически в любой среде.
Недостатки захвата пакетов и PCAP
Хотя захват пакетов является ценным методом мониторинга, он имеет свои ограничения. Анализ пакетов позволяет вам отслеживать сетевой трафик, но не контролирует все. Существует много кибератак, которые не запускаются через сетевой трафик, поэтому вам нужно принять другие меры безопасности.
Например, некоторые злоумышленники используют USB и другие аппаратные атаки. Как следствие, анализ файлов PCAP должен составлять часть вашей стратегии сетевой безопасности, но он не должен быть вашей единственной линией защиты.
Другим существенным препятствием для захвата пакетов является шифрование. Многие злоумышленники используют зашифрованные соединения для запуска атак в сетях. Шифрование не позволяет вашему анализатору пакетов получать доступ к данным трафика и выявлять атаки. Это означает, что зашифрованные атаки будут незаметны, если вы полагаетесь на PCAP.
Существует также проблема с тем, где находится анализатор пакетов. Если перехватчик пакетов размещен на границе сети, это ограничит степень видимости пользователя. Например, пользователь может не определить начало атаки DDoS или вредоносного ПО. Кроме того, даже если вы собираете данные в центре сети, важно убедиться, что вы собираете целые разговоры, а не сводные данные.
Инструмент анализа пакетов с открытым исходным кодом: как Wireshark использует файлы PCAP?
Другими словами, файл PCAP создает запись сетевых данных, которые вы можете просматривать через Wireshark. Затем вы можете оценить состояние сети и определить, есть ли какие-либо проблемы с обслуживанием, на которые вам нужно ответить.
Пример проприетарного инструмента анализа пакетов
Монитор производительности сети SolarWinds (БЕСПЛАТНАЯ ПРОБНАЯ ВЕРСИЯ)
Монитор производительности сети SolarWinds пример инструмента мониторинга сети, который может собирать данные PCAP. Вы можете установить программное обеспечение на устройстве, а затем отслеживать пакетные данные, извлекаемые из всей сети. Пакетные данные позволят вам измерить время отклика сети и диагностировать атаки..
Пользователь может просматривать пакетные данные через Панель управления качеством опыта, который включает в себя сводку производительности сети. Графические дисплеи упрощают определение всплесков трафика или вредоносного трафика, которые могут указывать на кибератаку.
Компоновка программы также позволяет пользователю дифференцировать приложения по объему трафика, который они обрабатывают. Факторы, такие как Среднее время отклика сети, Среднее время отклика приложения, Общий объем данных, и Общее количество транзакций помочь пользователю быть в курсе изменений, происходящих в сети в реальном времени. Существует также 30-дневная бесплатная пробная версия для загрузки.
Монитор производительности сети SolarWindsСкачать 30-дневную бесплатную пробную версию
Анализ файла PCAP: перехват атак в сетевом трафике
Инструменты захвата пакетов с открытым исходным кодом, такие как Wireshark и tcpdump, предоставляют сетевым администраторам инструменты для исправления низкой производительности сети, не тратя целое состояние. Существует также целый ряд фирменных инструментов для компаний, которые хотят более продвинутый опыт анализа пакетов.
С помощью файлов PCAP пользователь может войти в анализатор пакетов, собирать данные о трафике и видеть, где используются сетевые ресурсы. Использование правильных фильтров также значительно облегчит устранение белого шума и оттачивает самые важные данные..
Работаем с сетевыми адаптерами через Pcap-драйверы
Работой с сетью в наше время никого не удивишь. Насколько я знаю, работать с сокетами нынче обучают уже на втором курсе соответствующих специальностей. Так что в целом, сетевые навыки должны быть у многих программистов. Но иногда требуется не просто работать с сетью, а делать это с предопределёнными параметрами, будь то расстояние между пакетами либо какое-то нестандартное их содержимое. Понятно, что речь идёт не о повседневной жизни, а об отладке либо тестировании проектов. В этом нам поможет работа через Pcap-драйверы. Например, через драйвер Npcap, устанавливающийся вместе с программой Wireshark.
В целом, конкретно на Хабре наверняка найдётся много специалистов, которые знают, как это сделать. Но вот так получилось, что когда мне показали очень простое и удобное решение, я опросил своих коллег и выяснил, что о нём знает только тот, кто мне рассказал, да и тот уже забыл все детали. Он просто проект выдал и сказал, мол, делай по образу и подобию. И к уже материалам, имеющимся там, пришлось кое-что искать ещё в сети.
В общем, думаю, имеет смысл свести все сведения воедино. Кому интересно – приступаем!
Что следует скачать
Я буду работать под Windows. В сети сказано, что под Линуксом всё будет точно так же, но я не проверял. А под Windows исходно был драйвер WinPcap, а к нему шла библиотека. Гугль говорит, что имена функций на 100% совпадают с таковыми от Линуксовой libpcap. Потом драйвером WinPcap перестали заниматься, даже не было его 64-битной версии. Потом был разработан другой драйвер… Вообще, его имя Npcap, но чтобы не забивать голову лишней информацией, предлагаю более простой путь для поиска:
Просто скачиваем Wireshark и устанавливаем его. Он поставит актуальный драйвер, который по интерфейсу совместим с WinPcap, а значит – будет работать с библиотекой.
Также нам будет нужна библиотека. Мне всё досталось в виде базового проекта, но в целом, скачать нужные файлы можно отсюда: WinPcap · Developer Resources.
Повторю, не надо скачивать оттуда сам драйвер. Он устарел. На сайте всё верно написано. Но это не страшно. Что установится вместе с Wireshark – оно будет совместимо с этой библиотекой. Поэтому спокойно выбираем пункт Download WinPcap 4.1.2 Developer’s Pack и скачиваем архив. Нам понадобятся каталоги Include и Lib, содержащиеся внутри него.
Ну всё, теперь наша программная часть готова к бою. У нас установлен Wireshark и примкнувший к нему WinPcap-совместимый драйвер, и есть необходимые заголовочные файлы и библиотеки. Но перед началом опытов мы чуть-чуть настроим аппаратуру на уровне ОС.
Отключаем всё ненужное от сетевого адаптера
Сетевым адаптером могут управлять многие компоненты системы. Если посмотреть на его свойства, мы можем увидеть, какие подсистемы имеют к нему доступ:
Если прокрутить скроллер, будет ещё куча подсистем, и почти у всех установлены галочки. Для того адаптера, которым мы хотим управлять с высокой предсказуемостью, весь этот зоопарк лучше отключить. Понятно, что это должен быть специально выделенный адаптер. У меня в машине сейчас таких целых два. Когда я отлаживал Ethernet-анализатор, я слал пакеты с одного адаптера на другой, а анализатором ловил их. Сами адаптеры в отечественном Интернет-магазине стоили по 500 рублей, их доставили за день. Понятно, что это были адаптеры по акции, и не каждый день бывают такие цены, но в целом, добавить один-два адаптера к себе в ЭВМ особого труда не составит. Ещё раз обращаю, что я нашёл их в крупном отечественном Интернет-магазине, без привлечения АЛИ Экспресса.
Благодаря выделенному адаптеру, я буду уверен, что никто, кроме меня, ничего туда не пошлёт. Все пакеты будут или сформированы мною, или придут из подконтрольных мне мест. В общем, надо снять все галочки, кроме Pcap-овской. Так как мой Wireshark установил драйвер NPCAP, то галочка должна остаться только для него.
Готовим проект
В последнее время, я всё делаю с использованием Qt. Поэтому я скопировал в каталог со своим проектом папки Include и Lib из архива WpdPack_4_1_2.zip. Далее, я дописал в файл проекта такие строки:
В коде я использую такие заголовочные файлы:
Получаем список устройств
Чтобы открыть устройство «сетевой адаптер», надо выяснить его имя. Для этого имеются функция pcap_findalldevs(). Выделенную ею память надо будет освободить при помощи функции pcap_freealldevs().
Я покажу кусок кода, который не просто заполняет список в Qt-шном виджете, но ещё и устанавливает маркер на тот его элемент, который был запомнен при предыдущем открытии. Ну, чтобы не требовалось выбирать карту каждый раз.
В итоге, получаем что-то такое в списке:
Открываем устройство
Сам процесс открытия устройства прост и понятен. Необходимо и достаточно вызвать функцию pcap_open_live(). Пример вызова функции:
Здесь есть одна магическая константа – единица. На самом деле, это не что иное, как:
#define PCAP_OPENFLAG_PROMISCUOUS 1
Но я так и не смог найти способа правильного включения заголовочного файла, содержащего эту константу. Мало того, мне этот пример приехал тоже с магическим числом. Так что, похоже, не я первый.
Но не всё так просто, как хотелось бы. Адаптер недостаточно просто открыть. При самостоятельном формировании пакетов нам будет нужен его MAC-адрес. А когда я гонял данные с одного адаптера на другой – MAC-адреса обоих. Большинство примеров, которые я нашёл, при той схеме, которую я выбрал, не сработают. Они хороши, когда плата обслуживается кучей сетевых сервисов. Нет сервиса – нет возможности запросить у него MAC-адрес. А у меня все галки сняты. В результате массового опроса Гугля, был выстрадан следующий путь.
Сначала открываем карту при помощи уже известной функции:
А теперь – открываем адаптер на другом уровне. Там можно посылать системные запросы, в том числе, запрос на MAC-адрес. После чего адаптер того уровня можно закрыть.
Ну, и дальше я сохраняю идентификатор адаптера в файле конфигурации, чтобы при следующем входе в программу в списке был выбран именно он:
Вот теперь мы не просто открыли адаптер, но ещё и узнали его MAC-адрес, поэтому готовы к ручному формированию пакетов.
Формируем пакеты
Если честно, теория процесса формирования пакетов не относится к теме статьи. Я просто поискал в сети функции заполнения попроще. В том примере, который будет приложен в конце, я вызываю функцию void Dialog::CreatePacket().
В ней, среди прочего, есть такие строки:
Эти строки очень полезны не только при ручном формировании пакетов. Я брал штатные пакеты от обычных программ, которые наловил WireShark. Дальше пытался хоть подставить их в Verilog модель, хоть послать через PCap драйвер. Ethernet устройство упорно их игнорировало. Оказывается, WireShark отображает дамп уходящих пакетов без контрольных сумм UDP заголовка.
Вот я вижу два абсолютно идентичных пакета, пойманных WireSharkом. Один ушёл из PCap драйвера, второй — через сокеты. Никаких различий! Но устройство ловит только тот, что послан через сокеты. Снимаю дамп на стороне устройства — в PCap версии контрольная сумма отсутствует… Потому что она отсутствовала и в WireShark дампе. В общем, эти строчки помогут вам довести до ума пакеты, которые были сформированы другими программами и отловлены Wiresharkом.
Шлём пакеты по одному
Для посылки одиночных пакетов следует использовать функцию pcap_sendpacket().
Вот пример формирования и отсылки одиночного пакета:
Скоро мы узнаем, почему этой функцией не стоит пользоваться, если планируется посылка пачки пакетов. Но для одиночных – вполне себе полезная функция, так как она принимает в качестве аргументов указатель на данные и их длину, не требуя заполнять какие-то сложные структуры.
Принимаем пакеты
Есть несколько разных подходов к приёму пакетов. Так как мне в том проекте, где я впервые использовал libpcap, надо было ловить задержку от посылки пакета с одной карты до приёма на другой, я вынес этот функционал в отдельный поток. Для этого пришлось добавить такой простенький класс:
На всякий случай, потоковая функция запускается с повышенным приоритетом (поэтому в том проекте у меня иногда получалось, что пакет приходил раньше, чем завершалось выполнение функции его передачи).
Когда работа завершена, надо не забыть остановить принимающий поток, ведь следующий тест может потребовать запуска принимающего потока с другой логикой. Сейчас я просто жду в передающей функции секунду после посылки последнего пакета, а затем — взвожу флаг для принимающего потока, что он может завершаться. Ну, и жду сигнала о том, что завершение действительно произошло. Для тестового приложения этого достаточно:
Теперь – самое интересное. Внутри потока самое главное – это вызов функции pcap_next_ex(). В случае успешного завершения, она вернёт заголовок (в котором имеются длина и временная метка), а также блок данных. Полученные данные я сохраняю в связном списке. Главное его достоинство – при добавлении данных, он не перестраивается. А то доводилось мне заниматься оптимизацией одной программы, где автор массово добавлял данные в тогда ещё CByteArray, и она работала 40 минут. После замены динамического массива на связный список время работы уменьшилось до минуты… А после сборки не в Debug, а в Release конфигурации – до нескольких секунд. С тех пор я люблю связные списки для вещей, размер которых заранее не известен. А сколько лишних данных может прийти из сети – предсказать невозможно. Итак, потоковая функция выглядит так:
Забавный факт, связанный с функцией приёма
Кстати о невозможности предсказать объём приходящих данных. Пока я слал данные с одного адаптера на другой, я не обращал внимания на то, что функция приёма отловит не только приходящие пакеты, но и исходящие. Там для исходящего адаптера просто не шёл приём, вот я и не видел, что пакеты кто-то отлавливает.я. Ну, там всё работало так:
В текущем проекте у меня на проводе сидит устройство, которое модифицирует (инвертирует) пакеты и шлёт их назад.
И вот тут-то я обратил внимание, что читающий поток улавливает вдвое больше пакетов, чем я ожидаю. Проверил – точно. Ловятся и исходящие, и входящие. Проверил на версии с двумя платами: там — кто отсылает, ловит копии отосланных; кто принимает, ловит принятые. Так что дело именно в логике.
В общем, не пугайтесь, когда функция pcap_next_ex() будет принимать копии отосланного. Давайте я поясню суть сказанного на рисунке
Первый практический опыт использования
Давайте разбавим сухую теорию практикой. В настоящее время я адаптирую «прошивку» для работы с гигабитным Ethernetом к ПЛИС Lattice. И вот убеждаемся мы, что уровень PHY работает корректно, пора переходить к MAC. А он не работает! И что делать? Вытаскиваем наружу линию за линией, смотрим на них осциллографом, выясняем, что возникает ошибка CRC в поле FCS. Что дальше?
А дальше начинается веселье. Расчётное значение CRC зависит от дикого числа параметров. Когда сбой может идти откуда угодно, ничего не получится найти. Желательно оставить для начала что-то одно. И вот тут нам на помощь приходит возможность формировать абсолютно любой пакет данных. Просто берём и шлём пакет из одних нулей. В этом случае выходное значение зависит только от внутреннего регистра сдвига. Напомню, как вообще считается CRC (я возьму первый попавшийся рисунок, без привязки к именно нашей разрядности и именно нашему полиному):
То есть, в алгоритме имеется регистр сдвига и однобитовое входное значение. В параллельных алгоритмах добавляется некоторое количество логики, которая позволяет учитывать за один такт не один входной бит, а много. Но сколько бы их ни было, а будет выполняться операция XOR. Нулевое входное слово не будет вносить никаких изменений в том, что бегает по регистру сдвига. А значит, мы будем проверять только этот регистр и его обратные связи. Исправен – перейдём дальше. Нет – будем чинить его. Поэтому желательно для начала на вход подавать именно нули. Но пакет, ушедший через сокеты, будет содержать заголовок! При работе через Pcap-драйвер мы вполне можем послать пакет с заголовком из одних нулей! Это же замечательно!
А на отладочные линии, идущие из ПЛИС на анализатор, выведем и линии, соответствующие регистру сдвига. Как же я привык к хорошему! В Квартусе я бы воспользовался SignalTAPом, в Vivado – ILA. А тут надо выводить сигналы на настоящие контакты и подключать настоящий анализатор! Но так или иначе. Берём и подключаем. Вернее, сначала убеждаемся, что на входы блока приходят одни нули, если через Pcap послан пакет из одних нулей… Ну, то есть, система ничего не добавила по пути… Этот рисунок я публиковать не буду, поверьте на слово. А вот регистр – покажу. Анализатор у меня 16-битный, так что из данных я вывел только младший байт.
Я не нашёл, как в этой программе объединить биты в байт. Но посчитав пальцем, мы видим, что сначала там идёт 0xff, затем – 0x72, затем – 0x20. Дальше – не интересно. Потому что, взяв программную реализацию CRC и прогнав через неё все нули, мы получим последовательность для младшего байта 0xFF, 0x72, 0x00. Но и это ещё не всё! Если взять Верилоговский текст генератора CRC из этого проекта и прогнать его через ModelSim, мы получим в младших байтах всё те же 0xFF, 0x72, 0x00:
Пока я сделал вывод, что код для расчета CRC использует такой сложный синтаксис, что OpenSource компилятор Yosys неверно его синтезировал. Причём дело именно в логике. Даже для скорости 10 Мбит в секунду (тактовая частота будет 2,5 МГц), результат будет полностью идентичен. Взяв более простой исходник, мы получили работающий код. Там данные, пойманные логическим анализатором, совпадают с полученными хоть программным путём, хоть ModelSimом:
Правда, в найденном на замену исходнике пришлось перевернуть с ног на голову все биты в байте. Просто сначала я добился верной последовательности вот на этой диаграмме, потом – подал последовательность 0x01, 0x00, 0x00, 0x00… и увидел, что регистр сдвига ловит то, что вообще-то было бы при входе последовательности 0x80, 0x00, 0x00,0x00…Перевернул биты – всё стало хорошо. Если бы я не мог управлять потоком с точностью до байта, включая заголовок — искать врага пришлось бы дольше. Как бы я выкручивался, если бы пришлось посылать данные через обычные сокеты, ума не приложу! Использование Pcap-драйвера — просто находка для последовательного поиска врага!
Проблема передачи большого количества одиночных пакетов
Итак. Полученные знания уже позволяют нам проводить функциональное тестирование сетевых вещей. Но тестирование скоростных характеристик и устойчивости – увы, так не провести. Делаем простой пример. Передаём десять тысяч пакетов, каждый размером в килобайт.
10 мегабайт за 1.8 секунды. Это… Ну пусть 5 мегабайт в секунду. На гигабитной скорости (10 бит в байте) это 50 мегабит в секунду. Как-то медленно!
Но так как на принимающей стороне стоит ПЛИС, я могу вывести линии шины AXIStream (это почти как AVALON_ST, про которую я писал в куче статей, но только с небольшими особенностями) и посмотреть, как пакеты передаются, при помощи анализатора. Запускаем.
Уже тут видны паузы вплоть до 15 миллисекунд. Если чуть увеличить масштаб, увидим, что расстояния между пакетами равно примерно 200 микросекунд. Я покажу только линию строба. Когда она в единице, идёт перекачка данных по шине AXIStream, когда в нуле – шина простаивает:
Но мы видим, что шина дольше простаивает, чем работает. Это связано с тем, что система ради каждого пакета проваливается с пользовательского уровня на уровень ядра, а потом – возвращается на пользовательский уровень. Это очень дорогая операция. Чтобы устранить эту проблему, в библиотеке libpcap есть механизм, когда мы готовим очередь, а затем – единожды проваливаемся на уровень ядра. Давайте разберёмся, как он работает.
Передача с помощью очередей
Насколько мне удалось понять, функция передачи при помощи очередей была придумана специально для того, чтобы посылать ранее пойманные последовательности. По крайней мере, все найденные примеры именно читают последовательности из файла с ранее пойманными данными и посылают их. Собственно, нам надо сделать четыре шага:
Обратите внимание, что на третьем шаге уйти данные уйдут, но из очереди никуда не исчезнут. Я поначалу пробовал после окончания отсылки добавлять в неё новые пакеты для следующей пачки. Оказалось, что в следующий раз поедут и те, что уже были в ней, и новые. Так что первое, что приходит на ум — отправленную очередь можно разрушить, освободив память при помощи функции pcap_sendqueue_destroy(), после чего — снова создать новую, перейдя к шагу 1.
Также у меня возникла странная проблема, которую я объехал на серой козе. У меня же стояла задача проверять сторону ПЛИС, а не оптимизировать сторону ПК. Дело в том, что, если посылаем 100 пакетов подряд, они отлично доходят, а принимающий поток ловит и их копии, и все ответы от устройства. 1000 пакетов – десяток-другой ответов не доходят (теряются по пути туда или обратно – не разбирался). При пачке их десяти тысяч пакетов, терялась пара тысяч. Я не понял, что к чему. Я просто шлю пачками по 100 пакетов. Скорость при этом для моих задач приемлемая, потери равны нулю. Устойчивость «прошивки» ПЛИС всё равно подтверждается.
Итак, вот как выглядит передача очередями с учётом всего вышесказанного:
Тестовый прогон с очередью
Сравните времянку с той, которая была выше. Она снята в том же масштабе!
Внушает? Собственно, вот результаты замеров (10 мегабайт за 135 миллисекунд):
Примерно 75 мегабайт в секунду. То есть, 750 мегабит. Не гигабит, кончено… Просто если увеличить масштаб, мы увидим, что между каждой сотней пакетов всё равно есть те самые паузы по 200-300 мкс:
Но зато внутри блока мы видим вот такое соотношение работы и простоев:
Почти всё время единица, то есть, идёт передача данных по AXIStream! Пачка из сотни таких вещей не убивает «прошивку» в ПЛИС, а сотен уходит много, значит, начерно всё более-менее устойчиво. Так как я просто внедряю чужую Open Source разработку, этого достаточно, чтобы понять, что внедрено всё более-менее верно.
Что дальше
UDP – это хорошо, но как быть с более сложными протоколами? Тот пример, который мне выдали в качестве основы, обеспечивал высокоуровневые протоколы с помощью библиотеки LwIP. Так что никто не запрещает идти и этим путём. Но мне как-то было грустно думать, сколько времени я потрачу на освоение этой библиотеки и устранение проблем с нею, когда мне нужны не просто UDP-пакеты, а скорее даже UDP-подобные пакеты. Но кому надо – имейте в виду. Совершенно не обязательно мучиться. Можно просто взять LwIP.
Заключение
Мы освоили методику работы с сетью не через штатные сокеты операционной системы, а через ручное формирование и отправку пакетов. По ходу статьи мы рассмотрели два случая, где рассмотренный механизм является крайне необходимым. При необходимости, систему можно дополнить высокоуровневыми протоколами при помощи библиотеки LwIP (технология в статье не рассмотрена).
Социологический опрос
При разработке предыдущего блока статей я столкнулся с тем, что тема оказалась мало кому интересна. Поэтому теперь боязно начинать что-то большое, не выяснив, а нужно ли это общественности. С этой статьёй всё просто. Я уверен, что буду показывать её коллегам по мере возникновения задач у них. Плюс я уже один раз вспоминал, что к чему, когда делал тестовый проект для проверки «прошивки». Так что я сам же через год буду её читать.
Но работа с сетью на уровне пакетов – малая часть интересных вещей, которые удалось узнать, работая над проектом. Мы освоили работу с ПЛИС Lattice. Само по себе это особого интереса не представляет. Ну ПЛИС и ПЛИС, ещё один производитель, чего там интересного? А интересно там то, что разработка ведётся при помощи самых настоящих Open Source средств разработки. Оказывается, уже есть и такие! Но при использовании этих средств нужно иметь в виду кучку нюансов. Их можно было бы рассмотреть.
Но и это ещё не всё. Так получилось, что меня удручает долгая работа с инструментами для Линукса. Но оказывается, те самые Open Source средства можно собрать даже под Windows. Не в эмуляции Линукса под Windows, а просто под Windows. Опять же, сам процесс сборки кажется мне поучительным. Он расширяет кругозор по внедрению других разработок.
Также заказчик подкинул нам марку макетных плат, которые непонятно по какой причине стоят достаточно дёшево. Очень дёшево. Но продаются достаточно давно, чтобы списать это на простой демпинг. Себе я уже взял три штуки от жадности, хоть есть там и нюансы. Про них тоже можно было бы поговорить.
В общем, можно было бы рассмотреть всё это дело в виде нескольких статей. Но будет ли это интересно? Если нет, то лучше не тратить время на написание, а потратить его на что-то другое.