Comment 7 for bug 192174

another thing,
with Matteo's patch applied -B doesn't seem to output sequential (read consistent) streams.
new stream is being printed as soon as it's put together regardless if another stream is being printed at that moment, which results in streams being mixed together... which defeats the whole purpose of tcpflow :()
this, of course, doesn't happen if you save streams into files and then 'cat' them together.

to reproduce (requires tcpflow patched with http://launchpadlibrarian.net/11992351/20_stdout-dump.diff):

cd /tmp
mkdir dump; cd dump
# run two _parallel_ tcpflow processes in background
sudo su
tcpflow -i ethX 'port 80' &
tcpflow -i ethX -B > ../stdout.dump &

# run two parallel downloads
wget http://upload.wikimedia.org/wikipedia/commons/8/8a/Ptolemy_Cosmographia_Sarmatia%2BRha-river.jpg -O /dev/null & wget http://upload.wikimedia.org/wikipedia/commons/0/09/Skeleton_of_boiled_woman.jpg -O /dev/null

#when completed - stop tcpflow
killall tcpflow
cd ..

now edit stdout.dump and remove two HTTP GET headers and compare it with appropriate dump file from the first tcpflow instance, e.g:

hexdiff dump/remote.server.00080-local.ip.12345 stdout.dump

somewhere in the middle of 'stdout.dump' you will notice new HTTP header injected in the middle of binary JPEG data.

any ideas?