zainspirowany @sch tutaj jest wersja bash:
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
nazwa pliku będzie taka: stream number__time__source IP__port__destination IP__port.pcap
tr -d '\r'
jest dla użytkowników systemu Windows, ponieważ tshark w systemie Windows wyprowadza CR LF.
Edytuj :
to rozwiązanie z tshark jest takie wolne, ale pewne. SplitCap jest super szybki, ale gdy pojawia się błąd w pewnym pakiecie, ulega awarii, podczas gdy tshark informuje cię tylko o błędzie, ale kontynuuje:
tshark: The file "cap.pcap" appears to have been cut short in the middle of a packet.
i wreszcie jest PcapSplitter, który jest także super szybki, ale potrzebuje sterownika winpcap, nie działa ze sterownikiem npcap w systemie Windows.
Ale istnieje rozwiązanie SplitCap: za pomocą pcapfix mogę naprawić uszkodzone pakiety, wtedy SplitCap nigdy się nie zawiesza. i tego właśnie używam teraz, ponieważ tshark tak wolno dzieli.
a rozwiązaniem PcapSplitter, które zrobiłem, było wstrzykiwanie biblioteki dll winpcap za pomocą dowolnej metody, ale skoro mamy SplitCap, dlaczego to robisz?