tcpick-project Mailing List for tcpick: tcp stream tracker and sniffer (Page 3)
Status: Beta
Brought to you by:
duskdruid
Menu
▾
▴
tcpick-project — the tcpick project: submit here patches and feature requests
You can subscribe to this list here.
| 2004 |
Jan
(18) |
Feb
(2) |
Mar
(2) |
Apr
(15) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
(1) |
Sep
(9) |
Oct
(2) |
Nov
(6) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(7) |
| 2007 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(11) |
Oct
(9) |
Nov
(23) |
Dec
(35) |
| 2009 |
Jan
(4) |
Feb
(17) |
Mar
(21) |
Apr
(39) |
May
(48) |
Jun
(35) |
Jul
(29) |
Aug
(7) |
Sep
(3) |
Oct
(4) |
Nov
(5) |
Dec
(9) |
| 2010 |
Jan
(8) |
Feb
(7) |
Mar
(4) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2012 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(3) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2013 |
Jan
(6) |
Feb
|
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
(2) |
Feb
(4) |
Mar
(3) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: umit c. <u....@ya...> - 2012-06-28 00:19:36
|
http://fmuniversoarenales.com.ar/vvert.html |
|
From: umit c. <u....@ya...> - 2012-06-27 18:11:34
|
http://easyunlocks.com/gjrhbd.html |
|
From: Michael S. <mic...@gm...> - 2012-01-30 15:35:21
|
On 2012-W05-1, at 13:36, Michael Schwarz wrote:
> I hope this all helps to finding and fixing this bug, but if anyone needs any more information about my setup or wants me to run different tests, I'm very pleased to help!
I've given a shot at finding the problem myself. This is how far I got:
pcap calls got_packet() in loop.c for each captured packet. hdr-> len contains the length of the captured packet, hdr->caplen supposedly contains the amount of bytes that have been captured and are available under *packet. So I've put the following line at the beginning of got_packet():
printf("got_packet(): %p, %d, %d\n", hdr->caplen, hdr->len);
And got this output (only showing packets containing user data):
...
got_packet(): 0x5ea, 1514, 1024
got_packet(): 0x29a, 666, 1448
got_packet(): 0x5ea, 1514, 600
got_packet(): 0x29a, 666, 1448
got_packet(): 0x5ea, 1514, 600
got_packet(): 0x29a, 666, 1448
got_packet(): 0x442, 1090, 600
...
It seems that some of the packets are truncated, even though I do not understand why caplen is sometimes larger than len.
pcap_open_live() is called in tcpick.c to open the capture device. There, BUFSIZ is given as an argument to the snaplen parameter, which denotes the maximum number of bytes to capture of each packet. BUFSIZ is defined in stdio.h and is set to 1024 on my system. This obviously explains the truncated packets.
So I've set snaplen to BPF_MAXBUFSIZE instead, which is 2^15 on my system. This actually prevents the captured packets from being truncated, even though the output of the inserted printf does not change.
This seems to solve the problem, but it would be nice to know when a packet has been truncated and e.g. have the resulting stream not written to a file (maybe configurable via an option).
Michael |
|
From: Michael S. <mic...@gm...> - 2012-01-30 12:37:14
|
Hi I'm trying to use tcpick to restore transferred files from HTTP connections. For this I'm running tcpick like so: $ tcpick -i en0 -ap -wR 'port http' But most of the captured data is corrupted, similar to what was described by Penelope Fudd in KNOWN-BUGS. So I did some testing with capturing TCP streams containing test patterns and comparing the output of tcpick and Wireshark. I'm using netcat to send a file over a TCP connection that looks like this: 0------0------0------0------0------0------0------0------0------ 1------1------1------1------1------1------1------1------1------ 2------2------2------2------2------2------2------2------2------ ... I.e. 63 characters per line (plus a newline), each filled with the line number every 7 characters, 128 lines in total. The Python script to generate the file is attached. tcpick writes a file that is exactly 64 * 128 bytes long but every now and then some random data is inserted and some content is duplicated. The captured file is also attached. It seems there is a Pattern to the corruption: before byte 958: correct before byte 1024: random before byte 1982: correct before byte 2068: random before byte 2472: copy of data after 2472. (2472 is an estimate but seems fitting) before byte 4030: correct before byte 4116: random before byte 4520: copy of data after 4520. (again, an estimate) and so on ... The pattern becomes evident if the byte positions are compared to the payload sizes of the transmitted TCP packets. These are, according to Wireshark: packet 1: 1024 bytes packet 2: 1448 bytes (2472 bytes total) packet 3: 600 bytes (3072 bytes total) packet 4: 1448 bytes (4520 bytes total) It seems that packets 1, 2 and 4 have been captured at the correct position but the end of the payload (always starting at byte 958) has been corrupted by some random data and sometimes with data from the next packet (It seems fitting that packet 3 was too short to be corrupted). Sadly, this makes it impossible to use any of the data that's captured. Im using tcpick 0.2.1, installed using MacPorts on Mac OS X 10.6.8 (which builds the 32-bit-version). I hope this all helps to finding and fixing this bug, but if anyone needs any more information about my setup or wants me to run different tests, I'm very pleased to help! If you're trying to reach me a few months after I've written this message, it might be that I've unsubscribed from this list. So simply put me into your reply's CC so I'll get the message. Thanks everyone! Michael |
|
From: Tobia C. <tob...@gm...> - 2011-11-19 21:58:46
|
Chris Moore wrote: > I have exactly the same crash on a 64 bit archlinux install: > I fixed it by adding this line to lookup.h then running "make clean; make": > > char *lookup(); I added that line and did "make clean; make" as 64bit. Same crash as before. So this is not the fix, at least on OS X. For comparison the 32bit version has been running smoothly for hours at a time. Tobia |
|
From: Chris M. <do...@gm...> - 2011-11-18 22:24:21
|
I have exactly the same crash on a 64 bit archlinux install:
#2 0x00007fff8c15418e in vfprintf_l ()
#3 0x00000001000042a0 in color (attr=1051872, fg=1916690608,
out=0x10000596a, fmt=0x10000596a " %s:%s ") at colors.c:42
#4 0x00000001000020fa in display_status (out=0x7fff723e54e8,
conn=0x100100c30, status=SYN_SENT) at display.c:108
I fixed it by adding this line to lookup.h then running "make clean; make":
char *lookup();
The problem is caused by this missing function prototype. Lots more
prototypes are also missing, but adding this one this seems enough to
fix this particular bug.
Chris.
|
|
From: Tobia C. <tob...@gm...> - 2011-11-05 19:55:51
|
Hi all
I've always had trouble running tcpick on OS X, and was left with unwieldy substitutes such as Wireshark ;-)
Finally I took the time to debug it:
$ ./configure
$ make
$ sudo make install
$ sudo gdb tcpick
(gdb) run -i en0 -p -yP
Starting program: /usr/local/bin/tcpick -i en0 -p -yP
Reading symbols for shared libraries ++........................ done
Starting tcpick 0.2.1 at 2011-11-05 19:28 CET
Timeout for connections is 600
tcpick: listening on en0
.
.
[snip random traffic]
.
.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000723ebbd0
0x00007fff8c1b44f0 in strlen ()
(gdb) bt
#0 0x00007fff8c1b44f0 in strlen ()
#1 0x00007fff8c1558c3 in __vfprintf ()
#2 0x00007fff8c15418e in vfprintf_l ()
#3 0x00000001000042a0 in color (attr=1051872, fg=1916690608, out=0x10000596a, fmt=0x10000596a " %s:%s ") at colors.c:42
#4 0x00000001000020fa in display_status (out=0x7fff723e54e8, conn=0x100100c30, status=SYN_SENT) at display.c:108
#5 0x0000000100002c27 in status_switch [inlined] () at /Users/toby/src/tcpick-0.2.1/src/tracker.c:38
#6 0x0000000100002c27 in newconn (prev_ring=0x100100b80) at tracker.c:87
#7 0x0000000100003e50 in verify () at verify.c:139
#8 0x0000000100002857 in got_packet (useless=0x7fff723e54e8 "c;?", hdr=0x2c, packet=0x100007d90 "8?\a") at loop.c:101
#9 0x000000010001bea9 in pcap_read_bpf ()
#10 0x000000010001cd10 in pcap_loop ()
#11 0x0000000100003230 in main (argc=1916687592, argv=0x32ffffffff) at tcpick.c:264
(gdb) f 4
#4 0x00000001000020fa in display_status (out=0x7fff723e54e8, conn=0x100100c30, status=SYN_SENT) at display.c:108
108 color( c_CLIENTNAME_STATUS, out, " %s:%s ",
(gdb) p getportname(conn->client.port)
$2 = 0x100100ce0 "52906"
(gdb) p lookup(conn->client.ip)
$3 = 0x7fff723ebbd0 "192.168.7.100"
(gdb) p (char *)inet_ntoa(conn->client.ip)
$8 = 0x7fff723ebbd0 "192.168.7.100"
So tcpick crashes when printing the status line, in display_status().
display_status() calls color() with a fmt of " %s:%s " and two perfectly valid va_args: the strings returned by getportname() and by lookup(), the latter being inet_ntoa()'s static buffer.
Then, deep inside vfprintf(), some strlen() fails on the address 0x723ebbd0, which doesn't exist, but looks suspiciously similar to said static buffer at 0x7fff723ebbd0.
I tried inserting a strcpy() to my own static buffer in the code. This time strlen() fails on 0x73d0, where my static buffer was at 0x1000073d0.
What's going on here? My guess is that some piece of code inside the C library is casting the string pointers to 32bit, thereby losing the most significant half:
0x00007fff723ebbd0
0x00000001000073d0
^^^^^^^^
As to what damnable piece of code is doing so and why, I don't have a clue.
But at least it pointed me to the workaround: compiling tcpick as a 32bit executable.
$ CFLAGS=-m32 ./configure
$ make
$ sudo make install
You might want to put it in the README or on the website, or even make autoconf do it by default when it's on OS X, until someone figures out this riddle.
Tobia
|
|
From: umit c. <pro...@ya...> - 2011-04-18 10:46:45
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Yahoo!'da Arkadaşlarınızla ve Aile Bireylerinizle Bağlantı Kurun</title>
</head>
<body leftmargin="0" topmargin="0" bgcolor="#d2e4f0" marginheight="0" marginwidth="0">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td style="padding: 2pt 0pt 0pt 0pt;" align="center">
<table border="0" cellpadding="0" cellspacing="0" width="570">
<tbody>
<tr>
<td align="left"><img width="142" height="38" src="http://l.yimg.com/a/i/brand/purplelogo/base/tr.gif" alt="Yahoo!"></td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td style="padding: 10px 0pt 30px;" align="center" valign="top">
<table border="0" cellpadding="0" cellspacing="0" width="570">
<tbody>
<tr>
<td height="12" width="570"><img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/box_top.gif" height="12" width="570"></td>
</tr>
<tr>
<td align="center" background="http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bkg.gif" valign="top">
<table border="0" cellpadding="0" cellspacing="0" width="552">
<tbody>
<tr>
<td colspan="4"><img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_top.gif" height="17" width="552"></td>
</tr>
<tr>
<td background="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_left.gif" valign="top" width="6"><img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_left.gif" height="159" width="6"></td>
<td style="padding:5pt 0pt 0pt 12pt;" align="center" background="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bkg.gif" valign="top" width="125">
<a href="http://pulse.yahoo.com/_/PHOOOVM2MLQZBTKHG325DD2IHM?.gp=LliNfR2ZaMxMp84sCsXvmqt61FlbUsxlThd8stdzIbUrD1JpmR_kMeXhPnQK&q=0">
<img border="0" src="http://l.yimg.com/a/i/identity2/profile_192c.png" width="110" height="110">
</a>
<div style="margin:8px 0px 18px 0px;font-family:arial,verdana,helvetica;font-size:15px;"><a href="http://pulse.yahoo.com/_/PHOOOVM2MLQZBTKHG325DD2IHM?.gp=LliNfR2ZaMxMp84sCsXvmqt61FlbUsxlThd8stdzIbUrD1JpmR_kMeXhPnQK&q=0" style="color:#000000;text-decoration:none;">umit cavus (umit)</a></div>
</td>
<td style="padding: 5pt 15px 15px 15pt; font-family: Arial,Helvetica,sans-serif; font-size: 15px; color: rgb(51, 51, 51);" align="left" background="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bkg.gif" valign="top" width="415">
<strong><a href="http://pulse.yahoo.com/_/PHOOOVM2MLQZBTKHG325DD2IHM?.gp=LliNfR2ZaMxMp84sCsXvmqt61FlbUsxlThd8stdzIbUrD1JpmR_kMeXhPnQK&q=0" style="font-size: 17px;color: rgb(51, 102, 204);">umit cavus (umit)</a></strong>
<br>
<span style="font-size: 13px;">
Yahoo!'da sizinle bağlantı oluşturmak istiyor; böylece birbirinizin Güncellemelerini kolayca paylaşabileceksiniz
</span>
</td>
<td background="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_right.gif" valign="top" width="6"><img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_right.gif" height="159" width="6"></td>
</tr>
<tr>
<td colspan="4"><img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bot.gif" height="10" width="552"></td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td style="padding: 20px 30px;" align="left" background="http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bkg.gif" valign="top">
<img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/horz_div.gif" height="1" width="510">
</td>
</tr>
<tr>
<td style="padding: 0pt 30px 20px; font-family: Arial,Helvetica,sans-serif; font-size: 13px; color: rgb(51, 51, 51);" align="left" background="http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bkg.gif" valign="top">
<table border="0" cellpadding="0" cellspacing="0" width="510">
<tbody>
<tr>
<td colspan="2" align="left" height="25" valign="top" style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; color: rgb(51, 51, 51);">
<strong><span style="font-size: 15px;">
Kabul ettiğinizde, Yahoo!'da aşağıdakiler gibi Güncellemeleri paylaşmaya başlayacaksınız:
</span></strong>
</td>
</tr>
<tr>
<td align="left" valign="top" width="8">•
</td>
<td align="left" height="17" valign="top" width="502" style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; color: rgb(51, 51, 51);">
Durum mesajları, fotoğraflar, incelemeler ve çok daha fazlası
</td>
</tr>
<tr>
<td align="left" valign="top" width="8">•</td>
<td align="left" height="17" valign="top" width="502" style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; color: rgb(51, 51, 51);">
Kişi bilgisi değişiklikleri
</td>
</tr>
<tr>
<td align="left" valign="top" width="8">•</td>
<td align="left" width="502" style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; color: rgb(51, 51, 51);">
Otomatik doğum günü anımsatıcıları
</td>
</tr>
</tbody>
</table>
<br>
<a href="http://profiles.yahoo.com/accept/LliNfR2ZaMxMp84sCsXvmqt61FlbUsxlThd8stdzIbUrD1JpmR_kMeXhPnQK?q=0"><img src=" http://l.yimg.com/a/i/tr/mash/gr/accept_button.gif" alt="Daveti kabul et" border="0"></a>
<br><br>
Bu kullanıcının güncellemelerinizi görmesini Engellemek için <a href="http://pulse.yahoo.com/_PHOOOVM2MLQZBTKHG325DD2IHM">burayı</a> tıklatın.
<br>
</td>
</tr>
<tr>
<td height="12" width="570"><img src="http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bot.gif" height="12" width="570"></td>
</tr>
<tr>
<td style="padding: 13px 30px 0pt; font-family: Arial,Helvetica,sans-serif; font-size: 11px; color: rgb(51, 51, 51);" align="left" height="12" valign="top">
<a href="http://help.yahoo.com/l/tr/yahoo/profiles/updates/">Yahoo!'daki güncellemeler nedir</a>?
<br>
Bu davetin süresi 180 gün sonra dolacaktır.
<br>
Yahoo!'daki profiliniz ve bağlantılarınız hakkında hangi e-postaları aldığınızı denetlemek mi istiyorsunuz?<br>
Şuraya gidin: <a href="http://profiles.yahoo.com/settings/notifications" style="color: rgb(51, 102, 204); text-decoration: none;">http://profiles.yahoo.com/settings/notifications</a>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</body>
</html>
|
|
From: Christian B. <ch...@do...> - 2011-02-13 16:31:39
|
Hi, I've had the same problem some years ago. My solution was a simple patch to the tcpick output-routine, which printed the connection-identifier in front of each piece of data. That way a single script/program was able to partition the interleaved stream into multiple streams. I did use this to passively record HTTP connections and it worked pretty good. Some instructions to make that work (including the patch) can be found here: https://secure.jwall.org/web/tap/building_tcpick.jsp (Building a patched TCPICK) https://secure.jwall.org/web/tap/index.jsp (HTTP Recording with Java) Regards, Chris Am 07.02.2011 um 07:00 schrieb Chuck Lane: > I'm using a php script to parse input coming from tcppick. I've figured out how to get it working with one stream, however if I have multiple incoming streams on the same port I can't figure it out. > > Right now i'm using something like > > tcpick -bR "port xxx" | php5 ./myscript.php > > and reading the input in from stdin. > > Is there any way that I can make tcppick launch multiple instances of my script depending on how many connections are coming in > each one is on the same dest port but a different source port if that helps > > Thanks > > > -- > Chuck Lane > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb_______________________________________________ > Tcpick-project mailing list > Tcp...@li... > https://lists.sourceforge.net/lists/listinfo/tcpick-project |
|
From: Ian S. <ro...@ma...> - 2011-02-07 09:13:16
|
Chuck Lane wrote: > I'm using a php script to parse input coming from tcppick. I've figured > out how to get it working with one stream, however if I have multiple > incoming streams on the same port I can't figure it out. > > Right now i'm using something like > > tcpick -bR "port xxx" | php5 ./myscript.php > > and reading the input in from stdin. > > Is there any way that I can make tcppick launch multiple instances of my > script depending on how many connections are coming in > each one is on the same dest port but a different source port if that helps > I don't think you can do it with that form. You can get it to dump files - and then open them. Something like tcpick -a -i wlan0 -wR -F2 "port 8100"& You could also in principle in myscript.php, launch anotrher copy of tcpick when you first see data. This has a race condition - if multiple connections come in, one will be missed, and it won't trigger the next file till the first one sends data. |
|
From: Chuck L. <chu...@gm...> - 2011-02-07 06:00:12
|
I'm using a php script to parse input coming from tcppick. I've figured out how to get it working with one stream, however if I have multiple incoming streams on the same port I can't figure it out. Right now i'm using something like tcpick -bR "port xxx" | php5 ./myscript.php and reading the input in from stdin. Is there any way that I can make tcppick launch multiple instances of my script depending on how many connections are coming in each one is on the same dest port but a different source port if that helps Thanks -- Chuck Lane |
|
From: Asad <asa...@gm...> - 2010-09-19 09:21:50
|
Hi Is it possible to filter on connections. I want to display all conenctions except all connections going to one domain. For example all connections except connections to with destination to ".com" Regards Asad |
|
From: Ian S. <tc...@ma...> - 2010-09-01 13:37:08
|
I; was wondering if anyone else had ever seen tcpick use large amounts of RAM. Specifically - ps aux|grep tcp root 12366 2.1 18.8 389908 388316 pts/1 S+ Aug28 139:24 tcpick -a -i wlan0 -wR -F2 port 8100 And any thoughts as to the cause? Of course, I suspect on reviewing the archives that there is noone else here - but... |
|
From: umit c. <u....@ya...> - 2010-07-26 15:16:37
|
as i understand, tcpick does not support ipv6. I have to pick tcp sessions from a network traffic whose IP version is ipv6. Will be supported with ipv6 ? or if i want to write a patch, how can i start ? |
|
From: Dax M. <da...@da...> - 2010-04-05 16:11:09
|
I just installed tcpick on my Ubuntu 9.10 Desktop running 2.6.31-20-generic kernel. I was able to get some of the commands to work just fine. However once I added the "-t" option as soon as traffic is sent on the NIC the program aborts with the following message: <snip> daxm@LeeLoo:~$ sudo tcpick -i eth0 -C -h -a -t Starting tcpick 0.2.1 at 2010-04-05 09:50 MDT Timeout for connections is 600 tcpick: listening on eth0 *** buffer overflow detected ***: tcpick terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7f2eae505647] /lib/libc.so.6[0x7f2eae5045f0] tcpick[0x404dc2] tcpick[0x4025c5] tcpick[0x403281] /usr/lib/libpcap.so.0.8[0x7f2eae78499f] /usr/lib/libpcap.so.0.8(pcap_loop+0x59)[0x7f2eae788be9] tcpick[0x403a72] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f2eae42cabd] tcpick[0x4015f9] ======= Memory map: ======== 00400000-00408000 r-xp 00000000 fc:01 138641 /usr/sbin/tcpick 00608000-00609000 r--p 00008000 fc:01 138641 /usr/sbin/tcpick 00609000-0060a000 rw-p 00009000 fc:01 138641 /usr/sbin/tcpick 021d6000-021f7000 rw-p 00000000 00:00 0 [heap] 7f2ead3cd000-7f2ead3e3000 r-xp 00000000 fc:01 298 /lib/libgcc_s.so.1 7f2ead3e3000-7f2ead5e2000 ---p 00016000 fc:01 298 /lib/libgcc_s.so.1 7f2ead5e2000-7f2ead5e3000 r--p 00015000 fc:01 298 /lib/libgcc_s.so.1 7f2ead5e3000-7f2ead5e4000 rw-p 00016000 fc:01 298 /lib/libgcc_s.so.1 7f2ead5e4000-7f2ead5e6000 r-xp 00000000 fc:01 2780 /lib/libnss_mdns4.so.2 7f2ead5e6000-7f2ead7e5000 ---p 00002000 fc:01 2780 /lib/libnss_mdns4.so.2 7f2ead7e5000-7f2ead7e6000 r--p 00001000 fc:01 2780 /lib/libnss_mdns4.so.2 7f2ead7e6000-7f2ead7e7000 rw-p 00002000 fc:01 2780 /lib/libnss_mdns4.so.2 7f2ead7e7000-7f2ead7fd000 r-xp 00000000 fc:01 3584 /lib/libresolv-2.10.1.so 7f2ead7fd000-7f2ead9fc000 ---p 00016000 fc:01 3584 /lib/libresolv-2.10.1.so 7f2ead9fc000-7f2ead9fd000 r--p 00015000 fc:01 3584 /lib/libresolv-2.10.1.so 7f2ead9fd000-7f2ead9fe000 rw-p 00016000 fc:01 3584 /lib/libresolv-2.10.1.so 7f2ead9fe000-7f2eada00000 rw-p 00000000 00:00 0 7f2eada00000-7f2eada05000 r-xp 00000000 fc:01 3577 /lib/libnss_dns-2.10.1.so 7f2eada05000-7f2eadc04000 ---p 00005000 fc:01 3577 /lib/libnss_dns-2.10.1.so 7f2eadc04000-7f2eadc05000 r--p 00004000 fc:01 3577 /lib/libnss_dns-2.10.1.so 7f2eadc05000-7f2eadc06000 rw-p 00005000 fc:01 3577 /lib/libnss_dns-2.10.1.so 7f2eadc06000-7f2eadc08000 r-xp 00000000 fc:01 2781 /lib/libnss_mdns4_minimal.so.2 7f2eadc08000-7f2eade07000 ---p 00002000 fc:01 2781 /lib/libnss_mdns4_minimal.so.2 7f2eade07000-7f2eade08000 r--p 00001000 fc:01 2781 /lib/libnss_mdns4_minimal.so.2 7f2eade08000-7f2eade09000 rw-p 00002000 fc:01 2781 /lib/libnss_mdns4_minimal.so.2 7f2eade09000-7f2eade15000 r-xp 00000000 fc:01 3578 /lib/libnss_files-2.10.1.so 7f2eade15000-7f2eae014000 ---p 0000c000 fc:01 3578 /lib/libnss_files-2.10.1.so 7f2eae014000-7f2eae015000 r--p 0000b000 fc:01 3578 /lib/libnss_files-2.10.1.so 7f2eae015000-7f2eae016000 rw-p 0000c000 fc:01 3578 /lib/libnss_files-2.10.1.so 7f2eae016000-7f2eae40e000 rw-s 00000000 00:04 19214 socket:[19214] 7f2eae40e000-7f2eae574000 r-xp 00000000 fc:01 3569 /lib/libc-2.10.1.so 7f2eae574000-7f2eae773000 ---p 00166000 fc:01 3569 /lib/libc-2.10.1.so 7f2eae773000-7f2eae777000 r--p 00165000 fc:01 3569 /lib/libc-2.10.1.so 7f2eae777000-7f2eae778000 rw-p 00169000 fc:01 3569 /lib/libc-2.10.1.so 7f2eae778000-7f2eae77d000 rw-p 00000000 00:00 0 7f2eae77d000-7f2eae7af000 r-xp 00000000 fc:01 172929 /usr/lib/libpcap.so.1.0.0 7f2eae7af000-7f2eae9af000 ---p 00032000 fc:01 172929 /usr/lib/libpcap.so.1.0.0 7f2eae9af000-7f2eae9b0000 r--p 00032000 fc:01 172929 /usr/lib/libpcap.so.1.0.0 7f2eae9b0000-7f2eae9b1000 rw-p 00033000 fc:01 172929 /usr/lib/libpcap.so.1.0.0 7f2eae9b1000-7f2eae9b2000 rw-p 00000000 00:00 0 7f2eae9b2000-7f2eae9d1000 r-xp 00000000 fc:01 3566 /lib/ld-2.10.1.so 7f2eaebaf000-7f2eaebb1000 rw-p 00000000 00:00 0 7f2eaebcc000-7f2eaebd0000 rw-p 00000000 00:00 0 7f2eaebd0000-7f2eaebd1000 r--p 0001e000 fc:01 3566 /lib/ld-2.10.1.so 7f2eaebd1000-7f2eaebd2000 rw-p 0001f000 fc:01 3566 /lib/ld-2.10.1.so 7fff4ccf4000-7fff4cd09000 rw-p 00000000 00:00 0 [stack] 7fff4cdff000-7fff4ce00000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted daxm@LeeLoo:~$ </snip> -- "It is far better to grasp the Universe as it really is than to persist in delusion, however satisfying and reassuring." -- Carl Sagan |
|
From: Antos <on...@bv...> - 2009-12-25 21:41:51
|
Ry with a soft, impressionistic colour. Her eyes swept around the square, hastening over the great white apartment buildings, our modern atrocities, to linger over the old houses, which her swift imagination peopled with the fashion and pomp of another day. "Spring in the city!" breathed Bambi. "Spring in New York!" She was tempted to run to Jarvis's door and tap him awake, to drink it in too, but she remembered that Jarvis did not care for the flesh-pots, so she enjoyed her early hour alone. It was very quiet in the Park; only an occasional milk wagon rattled down the street. There is a sort of hush that comes at that hour, even in New York. The early traffic is out of the way. The day's work is not yet begun. There comes a pause before the opening gun is fired in the warfare of the day. Many a gay-hearted girl has sat, as Bambi sat, looking off over the housetops in this "City of Beautiful Nonsense," dreaming her dreams of conquest and success. Youth makes no compromise with life. It demands all, passionately; loses all, or wins, with anguish of spirit. So it was with Bambi, the high-handed, imperious little mite. She willed Fame and Fortune for Jarvis and herself in full |
|
From: Mathew B. <mat...@fa...> - 2009-11-23 18:35:47
|
Hi, I'm currently running into an issue when trying to write the output of both sides (client and server) of a conversation into a single file. My example pcap file is: http://forensicscontest.com/contest02/evidence02.pcap When I run: tcpick -r evidence02.pcap -yR -C "port 587", it shows the client-server sequence correctly as shown below (take special note of the AUTH LOGIN to AUTHENTICATION SUCCESSFUL part): 220 cia-mc06.mx.aol.com ESMTP mail_cia-mc06.1; Sat, 10 Oct 2009 15:35:16 -0400 EHLO annlaptop 250-cia-mc06.mx.aol.com host-69-140-19-190.static.comcast.net 250-AUTH=LOGIN PLAIN XAOL-UAS-MB 250-AUTH LOGIN PLAIN XAOL-UAS-MB 250-STARTTLS 250-CHUNKING 250-BINARYMIME 250-X-AOL-FWD-BY-REF 250-X-AOL-DIV_TAG 250-X-AOL-OUTBOX-COPY 250 HELP AUTH LOGIN 334 VXNlcm5hbWU6 c25lYWt5ZzMza0Bhb2wuY29t 334 UGFzc3dvcmQ6 NTU4cjAwbHo= 235 AUTHENTICATION SUCCESSFUL MAIL FROM: <sne...@ao...> >From the above, the sequence is correct (verified also using Wireshark). Also, when I select to write to file using the -wR option, it writes each side of the conversation / stream correctly (but each one in a different file): tcpick -r ../evidence02.pcap -wP "port 587". However, I'm running into issues when I try to put both sides of the conversation into the same file using the u option: tcpick -r ../evidence02.pcap -wPu "port 587". I end up with part of the authentication sequence at the very end instead of the beginning, which is definitely wrong (see below). Again, note the AUTH LOGIN and AUTHENTICATION SUCCESSFUL messages and where they are. Any ideas? Thanks. 220 cia-mc07.mx.aol.com ESMTP mail_cia-mc07.1; Sat, 10 Oct 2009 15:37:56 -0400 EHLO annlaptop AUTH LOGIN c25lYWt5ZzMza0Bhb2wuY29t NTU4cjAwbHo= MAIL FROM: <sne...@ao...> 250-cia-mc07.mx.aol.com host-69-140-19-190.static.comcast.net 250-AUTH=LOGIN PLAIN XAOL-UAS-MB 250-AUTH LOGIN PLAIN XAOL-UAS-MB 250-STARTTLS 250-CHUNKING 250-BINARYMIME 250-X-AOL-FWD-BY-REF 250-X-AOL-DIV_TAG 250-X-AOL-OUTBOX-COPY 250 HELP RCPT TO: <mis...@ao...> DATA Message-ID: <001101ca49ae$e93e45b0$9f01a8c0@annlaptop> From: "Ann Dercover" <sne...@ao...> To: <mis...@ao...> Subject: rendezvous Date: Sat, 10 Oct 2009 07:38:10 -0600 MIME-Version: 1.0 ... ... AAAhAKVR8wbYAQAA2QMAABAAAAAAAAAAAAAAAAAA5iMDAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAA AA0ADQBEAwAA9CYDAAAA ------=_NextPart_000_000D_01CA497C.9DEC1E70-- . 334 VXNlcm5hbWU6 334 UGFzc3dvcmQ6 235 AUTHENTICATION SUCCESSFUL 250 OK 250 OK 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF 250 OK QUIT 221 SERVICE CLOSING CHANNEL -- Mathew Brown mat...@fa... -- http://www.fastmail.fm - Send your email first class |
|
From: Christian B. <ch...@do...> - 2009-11-17 08:08:40
|
Hi Song,
that would be great. I'm not a c-programmer and failed to get tcpick
running on
64bit. Therefore I sadly hat to stop using it.
Can you provide a patch for testing?
Best regards,
Chris
Am 17.11.2009 um 08:45 schrieb Song Jiang:
> hi, every one:
>
> I have compiled tcpick under 64-bit platform. It always core dumps
> when capturing.
>
> The bug is that there is no declaration of function lookup(). So the
> compile uses "int lookup()" instead.
>
> But the really return value type of lookup() is "char *".
>
> There is no diff under 32-bit platform.
>
> Unlucky, "char *" is 8-byte and "int" is only 4-byte under 64-bit
> platform.
>
> We should make a declaration manually in order to fix this bug.
>
> Thanks.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
> Tcpick-project mailing list
> Tcp...@li...
> https://lists.sourceforge.net/lists/listinfo/tcpick-project
|
|
From: Song J. <son...@gm...> - 2009-11-17 07:45:37
|
hi, every one: I have compiled tcpick under 64-bit platform. It always core dumps when capturing. The bug is that there is no declaration of function lookup(). So the compile uses "int lookup()" instead. But the really return value type of lookup() is "char *". There is no diff under 32-bit platform. Unlucky, "char *" is 8-byte and "int" is only 4-byte under 64-bit platform. We should make a declaration manually in order to fix this bug. Thanks. |
|
From: Augustus W. <ldm...@ca...> - 2009-11-16 12:00:40
|
Looking for where to hide of shame? Our Chemists will help you. http://oah.znememinleb.com/ |
|
From: Tata D. <da...@i3...> - 2009-10-16 09:27:05
|
Hello, I have installed tcpick on our CentOS server to monitor traffic coming from port 21. We are only monitoring ftp access from our remote co-workers. I would like to know how to convert those IP address when the logs generated into their own names? And, is this possible? We are doing this one because we would like to monitor some protocol in implementing our application via ftp function. Thanks a million in advance. Sincerely, Tata |
|
From: Mingo <gui...@ca...> - 2009-09-02 12:00:14
|
S. 114 (1949). [454] 315 U.S. 203, 230 (1942). [455] Federalist No. 64. [456] _See also_ 40 Op. Atty. Gen. 250, 253 (1942). [457] 343 U.S. 579, 639, 640. [458] Ibid. 653, 654. [459] 343 U.S. 579, 657. [460] Ibid. 659. [461] 2 Cr. 170 (1804). [462] 343 U.S. 579, 662, 663. [463] Ibid. 662. [464] 343 U.S. 579, 678, 679. [465] Ibid. 705. [466] Ibid. 708-709. [467] 4 Wall. 475 (1867). [468] Ibid. 484. [469] Ibid. 500-501. [470] Kendall _v._ United States, 12 Pet. 524 (1838); United States _v._ Lee, 106 U.S. 196 (1882). It should be noted, however, that if the President fails to act, or if he adopts a narrow construction of a statute which he dislikes, and on this ground professes inability to act, the only remedy available against him is impeachment. [471] Noble _v._ Union River Logging R. Co., 147 U.S. 165 (1893); Philadelphia Co. _v._ Stimson, 223 U.S. 605 (1912). [472] Kendall _v._ United States, above; [Transcriber's Note: Reference is to Footnote 470, above.] United States _v._ Schurz, 102 U.S. 378 (1880); United States ex rel. Dunlap _v._ Black, 128 U.S. 40 (1888). _Cf._ Decatur _v._ Paulding, 14 Pet. 497 (1840); and Riverside Oil Co. _v._ Hitchcock, 190 U.S. 316 (1903), where the rule |
|
From: Ghee <tim...@sh...> - 2009-08-22 19:11:04
|
the day for Union and himself. How did he do it? I can demonstrate one way and with a rather personal incident. During the week I spent in Capetown Smuts was an absorbed person as you may imagine. The House was in session day and night and there were endless demands on him. The best opportunities that we had for talk were at meal-time. One evening I dined with him in the House restaurant. When we sat down we thought that we had the place to ourselves. Suddenly Smuts cast his eye over the long room and saw a solitary man just commencing his dinner in the opposite corner. Turning to me he said: "Do you know Cresswell?" "I was introduced to him yesterday," I replied. "Would you mind if I asked him to dine with us?" When I assured him that I would be delighted, the Prime Minister got up, walked over to Cresswell and asked him t |
|
From: McBrien Z. <ver...@ha...> - 2009-07-29 00:23:44
|
Energy Enhancement Meditation, Relaqtionships, sex, Audltery and Keeping Your Promises.www.wood96 . com |
|
From: Deus<sk...@ro...> - 2009-07-23 22:31:16
|
Marriage Relationsships - 6 Relationship Mistakes That Can Screw Up Your sex iLfe.www.pill99{.com}
|
357 messages has been excluded from this view by a project administrator.
![http://l.yimg.com/a/i/brand/purplelogo/base/tr.gif"](http://l.yimg.com/a/i/brand/purplelogo/base/tr.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/box_top.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/box_top.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bkg.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bkg.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_top.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_top.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_left.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_left.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bkg.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bkg.gif"){kind=link}
![http://l.yimg.com/a/i/identity2/profile_192c.png"](http://l.yimg.com/a/i/identity2/profile_192c.png"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_right.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_right.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bot.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/friend_bot.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/horz_div.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/horz_div.gif"){kind=link}
![http://l.yimg.com/a/i/tr/mash/gr/accept_button.gif"](http://l.yimg.com/a/i/tr/mash/gr/accept_button.gif"){kind=link}
![http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bot.gif"](http://l.yimg.com/a/i/us/ccs/ccs/7928/box_bot.gif"){kind=link}