что я получаю от бега:
tcpdump udp dst port 5201 -qUns 0 -i wlan0 -w file.pcap
только ip фрагментированные кадры.
Вероятно, это связано с тем, что любой трафик, идущий на порт 5201, состоит из пакетов UDP, которые больше, чем те, которые помещаются в один пакет канального уровня, поэтому IP должен их фрагментировать.
Этот фильтр, к сожалению, будет захватывать только первый фрагмент, потому что механизм фильтрации ОС, который использует libpcap, выполняет фильтрацию по пакетам без учета истории пакетов, и либо 1) первый фрагмент фрагментированного пакета UDP будет содержать полный заголовок UDP, а остальные не будут иметь никакой информации, чтобы идентифицировать их как дополнительные фрагменты этого фрагментированного пакета (без истории пакетов, идентификатор IP не помогает) или 2) сам заголовок UDP фрагментирован, и в этом случае фильтр не будет работать вообще (это, вероятно, никогда не случится на практике, но это не исключено RFC 791). Дополнительные фрагменты не будут захвачены, поэтому у вас не будет полного пакета.
(которые не дают мне фактическую информацию о скорости радиопередачи)
Если какой-либо пакет не имеет информации о скорости радиопередачи, это ошибка в драйвере для вашего адаптера; во фрагментарных IP-пакетах нет ничего, что могло бы заставить их не иметь информацию о скорости, в то время как другие пакеты ее имеют.
Почему, когда я фильтрую трафик на wireshark по IP [10] == 17 (который является полем протокола в заголовке IP), я получаю около 0,3% от общего результата, в то время как, если я пишу простое "udp" в текстовое поле фильтра отображения, я получаю 16% всех результатов и фрагментированные ip-пакеты скрываются?
Поскольку смещения в выражениях, таких как ip[10] == 17 начинаются с 0, поэтому первый байт будет ip[0] , и, следовательно, поскольку номер протокола является десятым байтом, правильным тестом для пакетов UDP будет ip[9] == 17 , а не ip[10] == 17 .
![Фильтр дисплея: ip [10] == 17](https://i.stack.imgur.com/qqnIq.png)