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.
>
Did you take a look at what I did to get tcpflow to behave as desired?
http:// launchpadlibrar ian.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, launchpadlibrar ian.net/ 11992351/ 20_stdout- dump.diff): upload. wikimedia. org/wikipedia/ commons/ 8/8a/Ptolemy_ Cosmographia_ Sarmatia% 2BRha-river. jpg-O /dev/null & wget upload. wikimedia. org/wikipedia/ commons/ 0/09/Skeleton_ of_boiled_ woman.jpg- O /dev/null server. 00080-local. ip.12345 stdout.dump /bugs.launchpad .net/bugs/ 192174
> 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://
>
> 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://
> http://
>
> #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.
>
> 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:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>