Automated Tcl ethernet captures in win2k
Dan
worth posting to it. Has anyone worked with or had to create an ethernet
sniffing app in tcl for win2k. I have a testing application that needs to
verify message flows between two ethernet devices and sniffing seems to be
the best way to see the entire message exchange. Currently we tell the test
operator to startup the sniffer application and start/stop the capture - no
real automation here and prone to operator error. We have been using
etherreal for the capturing and visual decoding, but find that exec'ing it
and then shutting down the capture becomes difficult. This would be simple
under unix with tcpdump, but we are dedicated to using win2k as the testing
platform.
Thanks,
Dan
Jeffrey Hobbs
>
> I have been a long-time reader of this group and finally have a question
> worth posting to it. Has anyone worked with or had to create an ethernet
> sniffing app in tcl for win2k. I have a testing application that needs to
> verify message flows between two ethernet devices and sniffing seems to be
Try http://sockspy.sourceforge.net/sockspy.html
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Sebastian Wangnick
Dan <dtor...@attbi.com> wrote in message
news:S0Ff8.21085$mG.86300@rwcrnsc54...
Dan
work on for a short time. Not sure about the sockspy app as it seems to
want to be run on the actual server machine rather than on a disitnerested
third party machine. I'll take a look at both.
Thanks again for the help.
Dan
"Dan" <dtor...@attbi.com> wrote in message
news:S0Ff8.21085$mG.86300@rwcrnsc54...
Cameron Laird
Dan <dtor...@attbi.com> wrote:
>Thanks Jeff and Sebastian - your ideas will give me some things to look and
>work on for a short time. Not sure about the sockspy app as it seems to
>want to be run on the actual server machine rather than on a disitnerested
>third party machine. I'll take a look at both.
.
.
No. sockspy is run on a third machine. What
gave you a different impression? We need to
correct anything that fails to make this clear.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Dan
like a scan - of the code. From that it looked like the app wanted to
reside on either the machine making the calls or the machine receiving them.
I did not see in the code anything that suggested the ability to watch
traffic outside of these conditions. I did not spend a long time looking at
the code so maybe you can help me to locate a bit more info so I can make
the right determination about sockspy. I also have not emailed the
maintainer of sockspy to get some help. I got real busy with the other
aspects of the test and will return to this portion later this week so your
comments are very timely. I should have something cobbled together this
week that I can begin testing in earnest and see which app really does what
I need.
Thanks,
Dan
"Cameron Laird" <cla...@starbase.neosoft.com> wrote in message
news:C44D512DFF6E2653.25901DCB...@lp.airnews.net...
Cameron Laird
>Well - since I could not find the docs on SF, I resorted to a quick - more
>like a scan - of the code. From that it looked like the app wanted to
>reside on either the machine making the calls or the machine receiving them.
>I did not see in the code anything that suggested the ability to watch
>traffic outside of these conditions. I did not spend a long time looking at
>the code so maybe you can help me to locate a bit more info so I can make
>the right determination about sockspy. I also have not emailed the
>maintainer of sockspy to get some help. I got real busy with the other
>aspects of the test and will return to this portion later this week so your
>comments are very timely. I should have something cobbled together this
>week that I can begin testing in earnest and see which app really does what
>I need.
.
.
Sockspy is way cool. Yes, it definitely lives (in general)
on a third, "proxy", host.
I'll probably write a brief sockspy tutorial this summer--I'm
backed up until then. In the meantime, maybe you can persuade
Keith or someone else to explain more.
km...@socrates.berkeley.edu
Cameron Laird <cla...@starbase.neosoft.com> wrote:
>In article <uC3h8.17582$T62.2917@sccrnsc02>, Dan <dtor...@attbi.com> wrote:
>>Well - since I could not find the docs on SF
> .
>Sockspy is way cool. Yes, it definitely lives (in general)
>on a third, "proxy", host.
>
>I'll probably write a brief sockspy tutorial this summer--I'm
>backed up until then. In the meantime, maybe you can persuade
>Keith or someone else to explain more.
Done. I basically took the v1.0 README, updated it for v2.0
and converted it into HTML.
The result is at: http://sockspy.sourceforge.net/sockspy.html
Keith
Dan
can't do. I'll take a stab at using it with my application and then pass on
my experience and possibly some meat for your tutorial as my thanks for
your - and the group's. help.
Dan
"Cameron Laird" <cla...@starbase.neosoft.com> wrote in message
news:082E332698C24C0E.04B0FF7C...@lp.airnews.net...
Dan
Cool - with this and some play time I think I may just get the picture.
Thanks for putting in the effort to get things done. I know I appreciate
it. I'll let you know how it goes as I do some playing.
Thanks,
Dan
<km...@socrates.Berkeley.EDU> wrote in message
news:a63i4a$1oep$1...@agate.berkeley.edu...
Sebastian Wangnick
I've written here called ipc (though ipc doesn't come with a GUI):
Usage: ipc [-s <suite>] [-c] [-d] [-i|-o|-k] [-y] [-t]
[-r <filename>|-] [-w <filename>|-]
[-[z|Z] <tracefile>[:<speed>]]
[-[p|P] [<fromrec>]-[<torec>]] <addr>
[-h <headerlen>] [-f <footerlen>] [-j <jumplen>] [-l
<lenlen>]
[-e]
where <suite> is one of:
unix (with <addr> as pathname of socket)
inet (with <addr> as [<hostname>:]<servicename>)
dli (with <addr> as [<taddr>:][<maddr>:]<sap>:<devname>) (for
DECNET/OSI on OSF1)
tp4 (with <addr> as <nsap>[@<tsap>]) (for DECNET/OSI on OSF1)
dna (with <addr> as <nsap>[@<tsap>[+<opt>]]) (for DECNET/OSI on
OSF1)
rmp (with <addr> as <tsap>@mac) (for propriatary Reliable Multicast
Protocol on OSF1)
x25 (with <addr> as <card>:(<device>|svc <calldata>)[:<remoteid>])
(for Sangoma X.25 card on Linux)
This is ipc, V1.11/1.17 as of Fri Aug 11 07:10:54 UTC 2000.
This program reads from the specified connection to stdout
and writes from stdin to the connection.
With -i, only stdin is connected.
With -k, the duplex socket is kept open until the partner closes.
With -o, only stdout is connected.
Flag -y requests to cycle, reopening the socket after closing it.
Flag -d requests datagram transport, default is stream.
Option -r appends data read from connection to <filename> or stderr.
Option -w appends data written to connection to <filename> or stderr.
Option -z (-Z) processes stdin according to <tracefile> stdin (stdout)
timing.
Option -p (-P) gives the range of records on stdin (connection) to process.
Flag -c requests client behaviour, default is server.
A server listens at a port for incoming data, and returns its data to
whereever
it received data latest from. Prior to receiving data, a server can send
data
only if an initial target address has been specified.
A client sends data to a fixed target address, possibly to multiple targets
in case of broad- or multicast.
With -t the operations performed are traced to stderr.
From each block of data read, a header is recognised,
followed by any number of data blocks, followed by a
footer. Data blocks have to contain their length in bytes
<jumplen> bytes from their beginning.
Each data block is send to stdout individually, with
the header prepended and the footer appended.
Flag -e signals encapsulation. When set, all data read from the connection
has its size (in network order) prepended on stdout,
and for data read from stdin this size is respected,
stripped, and collected before passing the data to the connection.
I can provide the source code if anyone is interested. This tool currently
requires a Unix file descriptor; it will thus not compile under Windows. I
was always planning of incorporating all these suites into Tcl, but only
managed for UDP (again, I can provide the sources if interest exists).
With this tool you can build "watch rings". For instance,
ipc -s unix -o /tmp/thesock | ipc -t -r read.log -w write.log
www.some.com:80 | ipc -s localhost:8000 | (sleep 5; ipc -s unix -c -i
/tmp/thesock)
will allow you to trace HTTP protocol traffic.
I tend to use it in Tcl via open "|ipc ..." to communicate via X.25 or TP4.
However, these approaches are all "intrusive" in that they require the
client to connect to a host or port different from the real server.
Ethereal, tcpdump and the like operate "non-intrusive" by watching the LAN
traffic itself (and performing dissectorisation and decoding as the real
network stack would do; this includes even re-assembly of fragmented packets
for TCP).
Regards,
Sebastian
<km...@socrates.Berkeley.EDU> wrote in message
news:a63i4a$1oep$1...@agate.berkeley.edu...
Cameron Laird
Sebastian Wangnick <sebastian...@eurocontrol.be> wrote:
>Ok, now I get the picture. Sockspy follows more-or-less the design of a tool
>I've written here called ipc (though ipc doesn't come with a GUI):
>
>Usage: ipc [-s <suite>] [-c] [-d] [-i|-o|-k] [-y] [-t]
> [-r <filename>|-] [-w <filename>|-]
> [-[z|Z] <tracefile>[:<speed>]]
> [-[p|P] [<fromrec>]-[<torec>]] <addr>
> [-h <headerlen>] [-f <footerlen>] [-j <jumplen>] [-l
><lenlen>]
> [-e]
.
.
>I can provide the source code if anyone is interested. This tool currently
.
.
Of course! 'Sounds worthwhile; you might even inspire
others to help you maintain and enhance it.