Двухпроходный фильтр в Wireshark/tshark

Варианты -Y, -2 и -R в tshark меня давно смущают.

После того, как я прочитал руководство, я знаю, что -Y используется в однопроходном фильтре и -2 в двухпроходном фильтре (в случае, если мы не можем получить некоторую информацию пока не закончится 1-й фильтр)

Но я так и не могу понять в чем разница между -2 -Y 'blabla' и -2 -R 'balabala' и -2 -Y 'blalal' -R 'blala'

И я также провел эксперимент, который сводил меня с ума:

tshark -n -r test.pcap -2 -R 'frame.number > 0'
  1   0.000000 10.140.28.17 -> 10.74.68.58  TCP 80 62276 > 8989 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=330325315 TSecr=0 SACK_PERM=1
  2   0.000056  10.74.68.58 -> 10.140.28.17 TCP 76 8989 > 62276 [SYN, ACK, ECN] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=2078759468 TSecr=330325315 WS=128
  3   0.000678 10.140.28.17 -> 10.74.68.58  TCP 68 62276 > 8989 [ACK] Seq=1 Ack=1 Win=131744 Len=0 TSval=330325316 TSecr=2078759468
  4   0.000756 10.140.28.17 -> 10.74.68.58  HTTP 158 GET /index.html HTTP/1.1
  5   0.000770  10.74.68.58 -> 10.140.28.17 TCP 68 8989 > 62276 [ACK] Seq=1 Ack=91 Win=29056 Len=0 TSval=2078759468 TSecr=330325316

Но когда я выполняю tshark -n -r test.pcap -2 -R 'frame.number > 1', ничего не печатается. Как это объяснить?

Моя версия tshark: TShark 1.10.6 (v1.10.6 от master-1.10)

Можете ли вы помочь мне с этой проблемой? Заранее спасибо!


wireshark tshark
person ruanhao    schedule 27.12.2016    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Я ответил на этот вопрос на https://ask.wireshark.org/questions/58343/2-pass-filter-in-wiresharktshark, но я также вставлю сюда свой ответ на случай, если кто-то будет искать ответ здесь, а не там.

-R указывает фильтр чтения, поэтому считываются и обрабатываются только соответствующие пакеты из файла; несопоставленные пакеты по существу обрабатываются так, как если бы файл их вообще не содержал. Сравните это с -Y, который указывает фильтр display, поэтому отображаются только соответствующие пакеты, но все пакеты по-прежнему считываются и обрабатываются.

Проблема, которую вы видите с frame.number, является известной ошибкой, которую уже давно не стоит исправлять. См. Ошибка 380, "wireshark -R не поддерживает 'frame.number' в качестве фильтра чтения ".

Вы также можете следить за историей -R против -Y здесь:

person Christopher Maynard    schedule 18.01.2017
comment
Спасибо за все ссылки на отчеты об ошибках и обсуждения в списках рассылки — приятно видеть хорошо документированные ответы, подобные этому. - person Eric Dand; 31.08.2017