inspirado en @sch aquí hay una versión 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
el nombre del archivo será así: stream number__time__source IP__port__destination IP__port.pcap
tr -d '\r'
es para usuarios de Windows, porque tshark en Windows genera CR LF.
Editar :
Esta solución con tshark es muy lenta pero segura. SplitCap es súper rápido, pero cuando hay un error en algún paquete, se bloquea, mientras que tshark solo le informa sobre el error, pero continúa:
tshark: The file "cap.pcap" appears to have been cut short in the middle of a packet.
y finalmente está PcapSplitter, que también es súper rápido, pero necesita el controlador winpcap, no funciona con el controlador npcap en Windows.
Pero hay una solución para SplitCap: usando pcapfix puedo reparar los paquetes corruptos y luego SplitCap nunca se bloquea nuevamente. y esto es lo que estoy usando ahora, porque tshark es muy lento en la división.
y una solución para PcapSplitter que hice fue inyectar el dll winpcap usando cualquier método, pero mientras tenemos SplitCap, ¿por qué hacerlo?