Re: [Tcpick-project] tcpick feature request

[Davi de C. R. <dav...@te...>]

Hello,

This is an interesting application. I use tcpick to create automated 
tests for my server applications. I simply let my users use the server 
application from the GUI frontend all day, and I log the commands the 
server receives (it uses a http-like communication protocol) using 
tcpick and redirecting it output to some file (e.g. LOG).
Then, when I want to reproduce the users commands, I just start my 
server in inetd mode and feed the commands through a pipe.
cat LOG | ./server --mode inetd > RESULTS
It is a very convenient tool to do benchmarks and to test server 
applications.

Unfortunatelly, tcpick prints (as dots) some header stuff together with 
the plain text protocol, despite the flags I used. Then I hacked loop.c 
to avoid syn packets (with or without a payload). So the line
if(flags.displaydata>0)
became
if(flags.displaydata>0 && (!tcppacket->syn))
and I could simply use my captured stream as an input for my server or 
netcat.

[]s
Davi


Francesco Stablum wrote:
> Hello John,
> What you have asked could be an interesting way to use tcpick, but I
> don't think of this feature as internal of the program, but "external".
> I mean tcpick could run easily like a web server, simply redirecting his
> output to a netcat session in listening mode.
> I think that in the next days i will develop a feature that should
> sound like this: "exit from tcpick after connection <num> is reached".
> Maybe it will added to the actual --pipe option.
> The idea of this "sniffing http server" ;-) will be this:
>  
> # yes "tcpick --pipe server \"port 80\" | nc -l -p 8000" | sh
>  
> In that way you could connect to localhost:8000 with a normal browser to
> see the files transmitted via http.
> But there are two problems, a little one and a big one.
> The little problem is that actually tcpick doesn't have a "exit when
> connection <n> closes" function. So you will see only the first file,
> but, be sure this is an option that will be added soon (in version
> 0.1.24 of course).
> The BIG problem is that images will be non displayed in the browser if
> they are "local" references. And maybe you will see on the browser
> images themselves, instead of html documents.
> Then, you could write a html page with an "auto-refresh" frame to have a
> costant updated view of the http files.
> 
> 
>