tshark не собирает фрагменты TCP в большие пакеты

У меня есть простой pcap с некоторым веб-трафиком, и я использую tshark для получения от него некоторой информации заголовка:

Я использую следующую команду:

tshark -r ./capture-1-5 -Y "http2" -o tls.keylog_file:ssl-key.log \
-T fields -e frame.number -e _ws.col.Time -e ip.src -e tcp.srcport \
-e ip.dst  -e tcp.dstport -e _ws.col.Protocol -e frame.len \
-e _ws.col.Info -E header=y -E separator="," -E quote=d \ 
-E occurrence=f > desegmented.csv

Я понял, что в этом случае все фрагменты пересобираются, что приводит к огромным пакетам. Однако мне не нужны пересобранные пакеты. Итак, я добавляю в tshark дополнительную опцию:

tshark -r ./capture-1-5 -Y "http2" -o tls.keylog_file:ssl-key.log \ 
-T fields -e frame.number -e _ws.col.Time -e ip.src -e tcp.srcport \
-e ip.dst -e tcp.dstport -e _ws.col.Protocol -e frame.len \
-e _ws.col.Info -E header=y -E separator="," -E quote=d \
-E occurrence=f -o tcp.desegment_tcp_streams:FALSE > segmented.csv

Моя интуиция подсказывает, что результирующий файл disassembled.csv должен быть больше по размеру и должен содержать больше строк, учитывая, что «пакеты выше MTU» будут отображаться как более одного пакета.

Однако я наблюдаю обратное. Результирующий файл без сборки меньше и содержит почти вдвое меньше строк.

-rw-r--r-- 1 root root 210K May 18 18:21 desegmented.csv
-rw-r--r-- 1 root root  97K May 18 18:21 segmented.csv

# cat desegmented.csv |wc -l
2635
# cat segmented.csv |wc -l
1233

Это нормальное поведение? Я не вижу (вручную), где начинают пропадать пакеты (и почему), и не вижу какой-либо закономерности из-за двусторонней связи (отсутствуют пакеты тут и там). Я предполагаю, что возможно, в случае disassebmled.csv каждый пакет или даже весь поток пакетов, в результате которого хотя бы один пакет превышает MTU, полностью отбрасывается.

Я также попытался применить ip.defragment: FALSE, но все равно получил те же результаты. Спасибо

Для воспроизведения файлы можно загрузить с здесь


person cs.lev    schedule 18.05.2020    source источник
comment
Тем временем я обнаружил пару сотен пакетов TCP и TLS, имеющих значение полезной нагрузки сегмента TCP/TLS повторно собранного PDU, которые определенно удалены из disassembled.csv. Затем, глядя на размеры пакетов в disassembled.csv, я обнаружил, что большинство пакетов, имеющих 4-значный размер, тоже отсутствуют (~ 200 пакетов). Тем не менее, у меня много пропущенных пакетов :S   -  person cs.lev    schedule 19.05.2020
comment
Я могу помочь, но вам нужно будет предоставить файлы в вашем вопросе (файлы pcap/log), чтобы другие могли воспроизвести это (т.е. MCVE). Возможно, вы столкнулись с поведением tshark, когда он будет выводить информацию о данных в текстовый вывод данных.   -  person Ross Jacobs    schedule 19.05.2020
comment
Добавил в текст, спасибо.   -  person cs.lev    schedule 19.05.2020
comment
У меня нет под рукой версии tshark, созданной с помощью TLS, поэтому я не смог воспроизвести. Однако обратите внимание, что при захвате отсутствует IP-фрагментация (фрейм является IP-фрагментом, если ip.flags.mf == 1 || ip.frag_offset › 0, что вы можете ввести в фильтр в wireshark). Ваш стек протоколов — http2/TLS/TCP/IP/Ethernet II. Фрагментация, которую вы видите, — это записи TLS, разделенные на несколько кадров TCP. Чтобы декодировать TLS и увидеть http2, вам нужно будет заново собрать сегменты TCP. Если вы этого не сделаете, вы сможете декодировать только те записи TLS, которые помещаются в один кадр.   -  person Jim D.    schedule 19.05.2020


Ответы (1)


Спасибо, @JimD., я уже пришел к подобному выводу! Сам захват пакетов должен быть сегментирован, чтобы сделать это точно.

Итак, попытался перейти на один уровень ниже и сделать так, чтобы сам захват пакета был сегментирован через

ethtool -K eth0 gso off tso off gro off sg off tx off rx off

(просто чтобы убедиться).

Проблема в том, что захват пакетов выполняется в док-контейнере, поэтому в нескольких местах я должен выполнить эту команду, чтобы она работала полностью. Эти места включают мост docker0, eth0 внутри контейнера и соответствующий vethXXXXXX на хосте, от которого второму требуются привилегированные контейнеры, которые создают дополнительные проблемы :)

person cs.lev    schedule 20.05.2020