Comment 8 for bug 192174

Did you take a look at what I did to get tcpflow to behave as desired?

http://launchpadlibrarian.net/18406455/tcpflow_patch_readme.txt

I am not much of a C hacker. Maybe it's better to start from scratch to get
the desired behavior, rather than starting w/ Matteo's patch?

- Rick

On Thu, Feb 25, 2010 at 11:31 AM, binary.koala <email address hidden>wrote:

> 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?
>
> --
> Allow binary dumping to stdout
> https://bugs.launchpad.net/bugs/192174
> You received this bug notification because you are a direct subscriber
> of the bug.
>