натхненний @sch ось баш-версія:
file=cap.pcap
$tshark -Tfields -e tcp.stream \
-e frame.time_epoch \
-e ip.src \
-e tcp.srcport \
-e ip.dst \
-e tcp.dstport -r $file |
sort -snu |
while read -a f; do
[[ "${f[5]}" ]] || continue # sometimes there is no stream number ex. UDP
fileout=$(echo ${f[0]}__${f[1]}__${f[2]}__${f[3]}__${f[4]}__${f[5]} | tr -d '\r' )
$tshark -r $file -2R "tcp.stream == ${f[0]}" -w "$fileout.pcap"
done
read
ім'я файлу буде таким: stream number__time__source IP__port__destination IP__port.pcap
tr -d '\r'
призначений для користувачів Windows, оскільки tshark у windows виводить CR LF.
Редагувати :
це рішення з цхарком настільки повільне, але впевнене. SplitCap дуже швидкий, але коли в деякому пакеті є помилка, він виходить з ладу, тоді як tshark повідомляє про помилку, але продовжуйте:
tshark: The file "cap.pcap" appears to have been cut short in the middle of a packet.
і, нарешті, є PcapSplitter, який теж надто швидко, але йому потрібен драйвер winpcap, він не працює з драйвером npcap у Windows.
Але є рішення SplitCap: використовуючи pcapfix, я можу виправити корумповані пакети, тоді SplitCap ніколи не вийде з ладу. і це те, що я зараз використовую, тому що цхарк так повільно розщеплюється.
і рішенням для PcapSplitter я вводив dll winpcap за допомогою будь-якого методу, але, хоча у нас є SplitCap, для чого це робити?