Authors of this application have been [Tom Poindexter], [Keith Vetter], and [Don Libes]. sockspy [ftp://ftp.procplace.com/pub/tcl/sorted/net/sockspy-1.0] "watch[[es]] the conversation of a Tcp client and server", according to its quite readable README [ftp://ftp.procplace.com/pub/tcl/sorted/net/sockspy-1.0/1.0/sockspy-1.0.README]. Although "not a replacement for heavy duty tools such as 'tcpdump' and other passive packet sniffers" (Ethereal [http://www.ethereal.com/], ...), it's easy to install, configure, and launch, and pleasingly convenient for "debugging Tcp client/server programs, examining protocols and diagnosing network problems". sockspy is nearly indispensable for any network programmer or network administrator, quite apart from any interest they might have in Tcl. [[Compare to tcpdump, ...]] ---- Version 2.0 of sockspy is available on sourceforge at [http://sourceforge.net/project/showfiles.php?group_id=45380&release_id=132854]. [http://sockspy.sourceforge.net/sockspy.html] documents sockspy. Among the new features are: * reorganized GUI to use one pane and different colors to indicate client, server and meta data * can be run as a command-line (tcl not tk) application. Before 2.0, sockspy was inherently Tk * you can stop, start and change the socket forwarding configuration from within the application Keith has also updated [http://sockspy.sourceforge.net/sockspy.html] Tom's version 1.0 tutorial. [[Nice work, Keith!]] ---- [Keith Vetter] 2003-01-09 - Version 2.4 is available on SourceForge here [http://sourceforge.net/projects/sockspy/]. To go straight to the download page, click here [http://prdownloads.sourceforge.net/sockspy/sockspy.zip?download]. Some release notes are avalable at [http://users.clover.net/keithv/sockspy.html]. [[NB. I had the wrong URL for the download so you may have gotten v2.0 instead of v2.4]] Among the new features are: * [HTTP] [proxy]ing--sockspy can use the first line of an HTTP request to determine who to forward to * an EXTRACT window, where data from the client and server streams matching user-supplied regular expressions are displayed. I use this to more easily see the URL a client is requesting and the status of the server's reply. ---- [Keith Vetter] 2003-03-03 - Version 2.5 is available on SourceForge here [http://sourceforge.net/projects/sockspy/]. This release comes courtesy of [Don Libes] who did the work. New features include: * timestamps (great for finding out where transactions are mysteriously pausing) * configuration file (and auto saving to it) * cmdline display [Steve Huntley] 2004-05-05: Sometimes stateFile will have spaces in it, especially on windows, in which case uplevel #0 source $stateFile will fail. I had to change to uplevel #0 source \"$stateFile\" in order to start sockspy. The annoying thing is, sockspy works the first time, but after the stateFile is created, it doesn't work subsequent times. See http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=f82c8ae7.0305090738.22b399e8%40posting.google.com ---- [JMN] 2003-07-01 Sometimes it's handy to be able to point an HTTP user-agent at sockspy without having to configure the sockspy address as the user-agent's proxy. The problem with 'fixed server forwarding' as it stands is that, not being specifically for HTTP, it doesn't allow you to connect to the correct virtual server on a webserver that relies on the HTTP Host header to direct requests. Fixed server forwarding is fine as it is however, for viewing many other protocols such as SMTP, POP3 or whatever. What's needed IMO is another option specifically for HTTP that either adds a Host header, or rewrites the existing one. Assuming this would be straightforward - I leapt in and started coding. Unfortunately, to do this robustly, sockspy needs to now have a proper concept of the parts of an HTTP request so that for example it doesn't rewrite a line in the body that coincidentally looks like an HTTP Host header line. Having a concept of HTTP requests means sockspy has to look for headers such as 'Content-Length' to determine if there is a body and how big it is.. assuming it's not using chunked encoding. I've managed to massage an experimental version into shape, that I find useful, but it's a bit unpolished and doesn't yet handle the chunked encoding of a request body. If anyone is interested in this addition, or if it's something that should be added to the project, email me at julian@precisium.com.au [AK]: When I used sockspy to debug some Cookie problem I noted that it does rewrite Set-Cookie and Cookie HTTP headers. [JMN]: I'd be surprised.. can't see a mechanism for it in the code. Are you sure there wasn't a transparent proxy of some sort upstream from it? Sockspy seems to just do a straight pass-through from one socket to another, just echoing the conversation to screen with no interference to the stream - which in most cases is what you want. Actually there's also a problem with the current HTTP proxy support in sockspy 2.5 anyway. It only grabs the destination URL at the time of the client's initial connection - but for a persistent HTTP/1.1 connection, the destination needs to be extracted from each new request-line in case the user has clicked off to another site, or even to display images linked from another site. Another problem is that a browser may open multiple connections, (not supposed to exceed 2 for HTTP/1.1). Sockspy's output window currently doesn't differentiate between connections, so you can't necessarily tell the difference between a pipelined request on a single request socket, and concurrent requests on 2 request sockets. (except that sometimes you'll see the two requests impossibly interleaved, so you know there must be multiple connections) I tried outputting the IP/Port combination to the left of the timestamp, but this starts to make the window look a little cluttered. A short numeric connection instanceID would probably be better, maybe with a hyperlinked key somewhere so that you can see the connection info? [AK]: I got my sockspy as starkit from the [sdarchive]. It might be different than yours. The browser was IE. The webserver a [tclhttpd] I had started myself. Sockspy on the same machine as the server, pointed to it. The browser was pointed directly to the port by sockspy. Tclhttpd got the correct cookies, and the sockspy log showed that sockspy got them a bit different, geared for it as server. So it had to rewrite them. I used cmdline mode btw., no windows. [jmn]: Most servers don't seem to explicitly set the domain in their cookies, in which case cookies should work just fine with a sockspy intermediary with no rewriting required. Can you define 'got them a bit different'? I downloaded the sdarchive version and the relevant code looks much the same. The only thing I can think of that you might be seeing, is that if prior to using sockspy your browser had already been issued cookies for that server, then when you put sockspy into the request path, the browser will no longer recognise the server as the one that issued the cookies, and so won't present them - thus the server will issue a new set. Does that seem plausible? ---- [Sebastian Wangnick] has an interesting complement to sockspy he calls [ipc]. [[Also explain relations to sniffers--tcpdump, ethereal, ..., and [pktsrc] ]] [[Also [moni].]] ---- [CL] plans a couple of articles in 2002-2003 on sockspy applications. [[Will December 2002 *Sys Ad* magazine [http://www.samag.com/articles/2002/] content be on-line?]] [[Try [http://www.samag.com/articles/2002/0212/] (the image wasn't linked properly)]][[There's still no link to the content of the article]] ---- [[ [Category Application] | [Category Internet] ]]