tcpick-project — the tcpick project: submit here patches and feature requests

[Tcpick-project] [PATCH] datalink.c (trivial)

[kirash <ki...@in...>]

--- datalink.c.old      Fri Mar 19 22:14:48 2004
+++ datalink.c 		Wed Apr 14 17:02:55 2004
@@ -187,6 +187,7 @@
     case DLT_LOOP:
       {
        ip_trasl=4;
+       break;
       }
 #endif
 #ifdef DLT_LINUX_SLL
@@ -200,6 +201,7 @@
     case DLT_PFLOG:
       {
        ip_trasl=28;
+       break;
       }
 #endif



-- 
GLS aka KIRASH

Re: [Tcpick-project] debian report for tcpick-0.1.22

[Francesco S. <dus...@in...>]

On Mon, 12 Apr 2004 11:22:38 +0200
Maurizio Lemmo - Tannoiser <tan...@te...> wrote:

> I've debian package for latest version. Francesco, i may put somewhere,
> and send you a link, or i may send directly to you, if you think could
> be useful.

Thank you very much for the package, Maurizio, I think the best thing is
if you please give me the link for the package, so I can update the
download page to link to it. 
Thank you, 
-Francesco 
--
http://francesco.stablum.info 
Key fingerprint = 521D DAD3 EB81 B62B FE35 E644 8CAD C1FC 66C8 246F 
Non mandatemi allegati in formati proprietari (msword, excel ecc.) uso GNU/Linux, preferite formati quali pdf, html e testo semplice (txt), grazie

[Tcpick-project] debian report for tcpick-0.1.22

[Maurizio L. - T. <tan...@te...>]

Hi, happy Easter everyone.

This is my test in debian enviroment, for tcpick version 0.1.22
(latest).

debian sid (unstable): compile and run correctly.
debian woody (stable): compile and run correctly.

I've debian package for latest version. Francesco, i may put somewhere,
and send you a link, or i may send directly to you, if you think could
be useful.

Let me know.

-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
BOFH excuse #416:

We're out of slots on the server

[Tcpick-project] tcpick 0.1.22 released!

[Francesco S. <dus...@in...>]

I am happy to announce that tcpick 0.1.22 sources are available for download!

Download
********
http://prdownloads.sourceforge.net/tcpick/tcpick-0.1.22.tar.gz?download

Changes
*******
  This version features some bugfixes, including important changes in the functions that write the dump to files. Now files are opened in "append" mode and data are written using the fwrite() function. A big change is that data captured are stored directly in files, without using heap allocating functions (i.e. malloc and calloc). This way much less memory will be used. 

ChangeLog
*********
07/03/04 0.1.22-test2
   * now output files are opened in "a" (only append) mode
   * now data are written with "fwrite()" + ferror (thanks ^^Gimli^^)
06/02/04 0.1.22-test1
   * corrected bug in datalinktoa() by sbi!
   * Davide Benini: corrected bug in calling S_calloc with only one
     argument
   * added S_malloc function
   * now data are written with the write() function

known-bugs
**********
  In some sessions, i.e. HTTP keep-alive, some data are written to
files "inside" a document. For example, an HTTP connection that
asks an image and a document in the same time will "mix" them.
The problem is most probably due to the "append" mode of the files;
I should try to invent something to distinguish these files.

In my opinion tcpick is now more stable than before; if you experience some segmentation failures, please send me a report, thanks.

-- Francesco Stablum
http://francesco.stablum.info
Key fingerprint = 521D DAD3 EB81 B62B FE35  E644 8CAD C1FC 66C8 246F
Non mandatemi allegati in formati proprietari (msword, excel ecc.)
uso GNU/Linux, preferite formati quali pdf, html e testo semplice (txt), grazie

tcpick 0.1.22-test2 released (was: Re: [Tcpick-project] Tcpick errors)

[Francesco S. <dus...@in...>]

Thank you very much for the hints, Penelope,
in fact the `-r' option has been very useful in the last debugging sessions.
Now I have just released tcpick version 0.1.22-test2 that is more stable, but I have not tested it enough to be sure of this.
After rewriting the data_write() and file_write() it seems that the strange segmentation faults have disappeared "magically".
I have seen tcpick tracking more than 15000 (!!!) connections last night using the -r option.
Well, I am quite satisfied for my work. Maybe tomorrow I will release 0.1.22 version, now I need to sleep.

Bye,
-Francesco

-- 
http://francesco.stablum.info
Key fingerprint = 521D DAD3 EB81 B62B FE35  E644 8CAD C1FC 66C8 246F
Non mandatemi allegati in formati proprietari (msword, excel ecc.)
uso GNU/Linux, preferite formati quali pdf, html e testo semplice (txt), grazie

[Tcpick-project] Tcpick errors

[Penelope F. <ke...@pk...>]

> hello,
> I have just released 0.1.22-test1 version of tcpick.
> This is only a testing version, for developers.
> 
> The problem:
> It is a month that I am not able to solve some SEGFAULT bugs. I have tried to see with gdb what is going on, but with no result.
> I have passed hours with gdb sessions and finally I am here to ask for help.
> If you want to help me, please download the latest unstable tcpick version from here:
> http://osdn.dl.sourceforge.net/sourceforge/tcpick/tcpick-0.1.22-test1.tar.gz
> after compiling it, run it on gdb, and after a few time it should (sigh) go in segfault.
> By the way: I have rewritten data_write() and file_write() functions.
> 
> thank you for the collaboration; I am available for any question
> 
> -Francesco Stablum

What you need is a tcpdump capture of some data that always causes the
problem:
  tcpdump -s0 -w /tmp/dump.tcpdump tcp&
  tcpick -whatever ; sleep 1; killall tcpdump
This should kill tcpdump 1 second after tcpick segfaults.  Hope you
aren't running tcpdump anywhere else on your system... :-)

Check it before doing anything further:
  tcpick -whatever -r /tmp/dump.tcpdump   ----> crash!

Then you can use tcpslice (which comes with tcpdump) to find out which
packets are causing it.  Use tcpslice to extract the last 10 seconds of
data, and see if tcpick can handle it.   If so, then 20 seconds.  Then
40.  Then 80.  In the worst case, it needs all of the packets.

I haven't learned how to use gdb yet.  I've been using printf, unlink
("---------point1"), and strace.  (Unlink isn't buffered and shows up in
strace quite well.  Just pick filenames that won't likely exist; a
filename starting with 8 dashes is a good example.)  I used to use
printf only, but it gave confusing results.

vi tcpick.c
make
strace -fo/tmp/a tcpick -whatever -r /tmp/dump.tcpdump
vi /tmp/a
   <repeat>

-- 
Penelope Fudd <ke...@pk...>

[Tcpick-project] tcpick 0.1.22-test1 released, with so many bugs

[Francesco S. <dus...@in...>]

hello,
I have just released 0.1.22-test1 version of tcpick.
This is only a testing version, for developers.

The problem:
It is a month that I am not able to solve some SEGFAULT bugs. I have tried to see with gdb what is going on, but with no result.
I have passed hours with gdb sessions and finally I am here to ask for help.
If you want to help me, please download the latest unstable tcpick version from here:
http://osdn.dl.sourceforge.net/sourceforge/tcpick/tcpick-0.1.22-test1.tar.gz
after compiling it, run it on gdb, and after a few time it should (sigh) go in segfault.
By the way: I have rewritten data_write() and file_write() functions.

thank you for the collaboration; I am available for any question

-Francesco Stablum

-- 
www.stablum.info
Key fingerprint = 521D DAD3 EB81 B62B FE35  E644 8CAD C1FC 66C8 246F

The number of UNIX installations has grown to 10, with more expected.
 -- The UNIX Programmer's Manual, Second Edition; June 1972

Re: [Tcpick-project] debian feedback (and package) : release 0.1.21

[Francesco S. <dus...@in...>]

On Mon, 29 Mar 2004 18:41:57 +0200
Maurizio Lemmo - Tannoiser <tan...@te...> wrote:

> Tested version: 0.1.21 (latest)
> Tested platform: Debian unstable (sid), Debian stable (woody)
> Result: compile and run perfectly on both platform

Thank you very much for this, Maurizio;
unfortunately tcpick doesn't seem to work right due to some segmentation failures (if you let tcpick on a high-traffic network interface it will happen in a few minutes). I have tried several times to understand what is going on by debugging it with gdb. 
I am trying to find somebody to help me, but obviously people don't like debugging.

> I made two (unofficial) deb package of tcpick, i may sent you if you think
> could be useful. Let me know what you think about.

I think it is a very good idea! And it is a good idea if they stay "unofficial" too, at the moment :)

Bye
Francesco

-- 
www.stablum.info
Key fingerprint = 521D DAD3 EB81 B62B FE35  E644 8CAD C1FC 66C8 246F

The number of UNIX installations has grown to 10, with more expected.
 -- The UNIX Programmer's Manual, Second Edition; June 1972

[Tcpick-project] debian feedback (and package) : release 0.1.21

[Maurizio L. - T. <tan...@te...>]

Tested version: 0.1.21 (latest)
Tested platform: Debian unstable (sid), Debian stable (woody)

Result: compile and run perfectly on both platform

I made two (unofficial) deb package of tcpick, i may sent you if you think
could be useful. Let me know what you think about.

(i switch to english version, 'cause recent message on this list).

-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
Spike: "It's a big rock. Can't wait to tell my friends. They don't have a rock this
big."
	--Buffy the Vampire Slayer: Becoming (Part 1)

Re: [Tcpick-project] Patch: allow tcpick to read from a tcpdump file

[Francesco S. `D. <dus...@in...>]

Thank you very much for the patch, Penelope Fudd
This is a very nice feature, I have added it to the new version of tcpick, that will be released not so soon because of too many code cleanings in the connection tracking system.

Thank you,
Francesco Stablum aka duskdruid

On Mon, 23 Feb 2004 14:19:03 -0800
Penelope Fudd <ke...@pk...> wrote:

> Hello!
> 
> Here is a patch (for tcpick-0.1.20) that allows you to say:
> 
> tcpdump -n -s 1600 -w /tmp/foo.tcpdump
> tcpick -r /tmp/foo.tcpdump
> 
> and it will process the saved file instead of a live connection!
> -- 
> Penelope Fudd <ke...@pk...>
> 


-- 
www.linux.it/~stablum
Key fingerprint = 521D DAD3 EB81 B62B FE35  E644 8CAD C1FC 66C8 246F

[Tcpick-project] Patch: allow tcpick to read from a tcpdump file

[Penelope F. <ke...@pk...>]

Hello!

Here is a patch (for tcpick-0.1.20) that allows you to say:

tcpdump -n -s 1600 -w /tmp/foo.tcpdump
tcpick -r /tmp/foo.tcpdump

and it will process the saved file instead of a live connection!
-- 
Penelope Fudd <ke...@pk...>

[Tcpick-project] tcpick 0.1.20 released!!!

[Francesco S. `D. <dus...@in...>]

Yes, the new version of tcpick is available for download.

Changes:
30/01/04 0.1.20
* added:
  - displaying of unprintable carachters (that are also dots in -P option) 
    with red color.
  - added hexdump mode colorizer
  - with option -C2 it is now possible see different colors depending on
    the connection tracked (only status banners) (file colortrack.c)
  - added connection numbering (first field in status banner)
  - added time writing on banners and packet headers(time.c)

Happy sniffing ;)
Francesco "duskdruid"
-- 
www.linux.it/~stablum

Re: [Tcpick-project] released tcpick 0.1.19 with colors (!)

[Francesco S. `D. <dus...@in...>]

On Fri, 16 Jan 2004 18:21:53 +0100
kirash <ki...@in...> wrote:

> avrei preferito una colorazione basata sulle connessioni
> tracciate invece che sul tipo di pacchetto.
> un colore diverso per ogni stream tcp per meglio
> visualizzare a chi appartiene un determinato pacchetto.

buona idea! Adesso sviluppo questa nuova feature...
ciao
Francesco "duskdruid"
-- 
www.linux.it/~stablum

Re: [Tcpick-project] released tcpick 0.1.19 with colors (!)

[kirash <ki...@in...>]

On Thu, 15 Jan 2004 17:29:04 +0000 Francesco wrote:

> Yes! Now tcpick 0.1.19 has colors too! You can enable them by
> using -C (or --colors) option.


avrei preferito una colorazione basata sulle connessioni
tracciate invece che sul tipo di pacchetto.
un colore diverso per ogni stream tcp per meglio
visualizzare a chi appartiene un determinato pacchetto.


-- 
GLS aka KIRASH

[Tcpick-project] released tcpick 0.1.19 with colors (!)

[Francesco S. `D. <dus...@in...>]

Yes! Now tcpick 0.1.19 has colors too! You can enable them by using -C (or --colors) option.
Fixed other bugs and incompatibilities with other Unix platforms (AIX, for example).

Here is the ChangeLog:
[cut]
15/01/04 0.1.19
* added:
  - <pcap/pcap.h> header support (i.e. trustix)
  - DLT_PFLOG/DLT_NULL/DLT_RAW/DLT_IEEE802_11 header support (not tested!!!)
  - datalinktooffset function (datalink.c)
  - Push/Fin/Ack packet support
  - support for those systems that don't have getopt_long and getopt.h
    header (was a problem in AIX systems, thank you Alberto
    'JCN-9000' Varesio)
  - experimental color option (-C): it is very nice!
    It should be helpful to read the output of tcpick.
  - new file colors.c (read code comments to know about the original author)
[/cut]

Enjoy ;)
-- 
www.linux.it/~stablum

[Tcpick-project] tcpick 0.1.18 rilasciato :-)

[Francesco S. `D. <dus...@in...>]

Signore e signori, ecco a voi tcpick versione 0.1.18 :)
dunque, dopo aver fixato quel bug del "resulting_bool==" ho aggiunto gli stati FIN-WAIT-2, TIME-WAIT e CLOSED, dopo aver riscritto le funzioni che si occupano di aggiornare lo stato della connessione.
Ora si puo' dire che tcpick sta leggermente tendendo verso la completezza.
Per quanto riguarda le prossime due versioni, saranno incentrate sulla compatibilita' verso i sistemi bsd (domani mi arriva l'hd nuovo e posso quindi provare Open/FreeBSD).
Per qualsiasi cosa non esitate a postare in ml.
Alla prossima
Francesco "duskdruid"
-- 
www.linux.it/~stablum

Re: [Tcpick-project] tcpick-0.1.18-test3 e bug irragionevole

[Francesco S. `D. <dus...@in...>]

On Sun, 11 Jan 2004 16:14:11 +0000
Francesco Stablum `DuskDruid' <dus...@in...> wrote:

>     50        resulting_bool==resulting_bool&&(conn->status==status);
ecco perche' non veniva compilato: `==' invece di `='
Da aggiungere alla lista dei bug ridicoli :)
ciao
Francesco
-- 
www.linux.it/~stablum

Re: [Tcpick-project] tcpick-0.1.18-test3 e bug irragionevole

[kirash <ki...@in...>]

On Sun, 11 Jan 2004 16:14:11 +0000 Francesco wrote:

> Gia', proprio irragionevole, in quanto sembra che ci sia un'istruzione
> che non viene proprio eseguita e sarebbe nel file match.c, 
> nella funzione match.c, alla linea 48.
> [cut]
>     48    if(status!=-1)
>     49      {
>     50        resulting_bool==resulting_bool&&(conn->status==status);
>     51      }
> [/cut]

premetto che ho dato uno sguardo veloce e che non ho 
idea del significato delle variabili in causa...

a parte gdb cosa ti fa pensare che non entra?
a me pare tutto corretto, prova a far stampare
una frase ogni volta che si entra nell'if e vedrai che l'if
viene eseguito per tutti i valori di status diversi da -1



-- 
GLS aka KIRASH

[Tcpick-project] tcpick-0.1.18-test3 e bug irragionevole

[Francesco S. `D. <dus...@in...>]

Gia', proprio irragionevole, in quanto sembra che ci sia un'istruzione che non viene proprio eseguita e sarebbe nel file match.c, nella funzione match.c, alla linea 48.
[cut]
    48    if(status!=-1)
    49      {
    50        resulting_bool==resulting_bool&&(conn->status==status);
    51      }
[/cut]
tutto cio' e' verificabile anche tramite gdb:
[cut]
    42      {
    (gdb) s
    43        int resulting_bool=1; /* this should be always 1 although
    (gdb) s
    53        if(urg!=-1)
[/cut]
Ho rilasciato il pacchetto -test3, che potete scaricare al solito posto (grazie kirash per la segnalazione)
Qualche idea?
Grazie
Francesco
-- 
www.linux.it/~stablum

Re: [Tcpick-project] bug delle connessioni dopo il primo tracciamento

[Francesco S. `D. <dus...@in...>]

On Sun, 11 Jan 2004 11:31:14 +0100
kirash <ki...@in...> wrote:

> > Tcpick-0.1.18-test2 e' online
> 
> e' danneggiato

ARGH! e l'incubo si ripete... tra poco vedrai il -test3
grazie per la segnalazione

Ciao
Francesco

Re: [Tcpick-project] bug delle connessioni dopo il primo tracciamento

[kirash <ki...@in...>]

On Sat, 10 Jan 2004 15:52:31 +0000 Francesco wrote:

> Tcpick-0.1.18-test2 e' online

e' danneggiato

-- 
GLS aka KIRASH

Re: [Tcpick-project] bug delle connessioni dopo il primo tracciamento

[Francesco S. `D. <dus...@in...>]

Ciao a tutti

Il bug e' stato risolto
era semplicemente un if senza graffe (sigh)
Scusate il disturbo

Tcpick-0.1.18-test2 e' online

bye
Francesco
-- 
www.linux.it/~stablum

[Tcpick-project] bug delle connessioni dopo il primo tracciamento

[Francesco S. `D. <dus...@in...>]

Ho di nuovo raccolto le energie e mi sono concentrato su gdb. (tcpick 0.1.18-test1)
Niente da fare, l'indirizzo di *tcppacket passato alla verify() cambia, inspiegavolmente, irrazionalmente e lo snip che vedete in fondo ne e' la prova palese.
Non mi rimane che mettermi le mani nei capelli, oppure affidarmi alla vostra esperienza.
Sembra che il problema sia abbastanza a basso livello. 
Mi sono accorto che la funzione chiamata dalla pcap_loop (ovvero got_packet) ha come secondo argomento 0xbffff8d0 e, guarda caso, e' lo stesso argomento che viene passato a verify().
Personalmente non me ne intendo, ma puo' darsi che sia in qualche modo un'implementazionne errata dello stack (quello hardware, dove vengono memorizzati gli argomenti delle funzioni)?
Ah, ho gcc versione 3.2.3, gdb 5.3, linux 2.4.22

Grazie
Francesco

(segue l'output di gdb)

[snip]
Breakpoint 1, got_packet (useless=0x0, hdr=0xbffff8d0, packet=0x806a8d8 "") at loop.c:175
175                 payload_len=hdr->len-(int)(payload-packet);/*calculate lenght of data section*/
(gdb) p *tcppacket 
$10 = {source = 34433, dest = 6400, seq = 2827910518, ack_seq = 0, res1 = 0, doff = 10, fin = 0, syn = 1, rst = 0, psh = 0, ack = 0, 
  urg = 0, res2 = 0, window = 53270, check = 1955, urg_ptr = 0}
(gdb) p tcppacket 
$11 = (struct tcphdr *) 0x806a8fc
(gdb) s
176                 verify(ippacket,tcppacket,payload,payload_len); /* verify the packet*/
(gdb) s
verify (ippacket=0x806a8e8, tcppacket=0xbffff8d0, payload=0x806a914 "\004\002\b\n", payload_len=16) at stack.c:248
248      if(match(*stack_ptr,ippacket,tcppacket,
(gdb) p tcppacket 
$12 = (struct tcphdr *) 0xbffff8d0
(gdb) p *tcppacket 
$13 = {source = 60843, dest = 16381, seq = 651146, ack_seq = 76, res1 = 12, doff = 4, fin = 0, syn = 0, rst = 0, psh = 0, ack = 0, 
  urg = 0, res2 = 0, window = 0, check = 17, urg_ptr = 8}
(gdb) bt
#0  verify (ippacket=0x806a8e8, tcppacket=0xbffff8d0, payload=0x806a914 "\004\002\b\n", payload_len=16) at stack.c:248
#1  0x08049ff4 in got_packet (useless=0x0, hdr=0xbffff8d0, packet=0x806a8d8 "") at loop.c:176
#2  0x0804c38e in pcap_read_packet ()
#3  0x0804d68d in pcap_loop ()
#4  0x0804b504 in main (argc=-1073743068, argv=0x806a6f8) at tcpick.c:471
#5  0x4003dd06 in __libc_start_main () from /lib/libc.so.6
(gdb) 
[/snip]
-- 
www.linux.it/~stablum

Re: [Tcpick-project] feedback: debian (sid e woody)

[Francesco S. `D. <dus...@in...>]

Innanzitutto ti ringrazio per la segnalazione,

On Thu, 8 Jan 2004 18:01:26 +0100
Maurizio Lemmo - Tannoiser <tan...@te...> wrote:

> tcpick.c:170: `DLT_PPP_ETHER' undeclared (first use in this function)
> tcpick.c:195: `DLT_LTALK' undeclared (first use in this function)
Dunque, questo *dovrebbe* essere risolto nella 0.1.18-test1

> tcpick.c:214: parse error before `static'
> tcpick.c:233: `long_options' undeclared (first use in this function)
> tcpick.c:233: `option_index' undeclared (first use in this function)
Molto bene, a quanto pare il compilatore gcc "vecchio" non sopporta le dichiarazioni in mezzo al codice. Ora l'ho corretto e dovrebbe essere compatibile, tra qualche giorno sui vostri schermi :)

Ciao
Francesco
-- 
www.linux.it/~stablum

[Tcpick-project] Re: tcpick e BSD - patch 2

[kirash <ki...@in...>]

On Thu, 8 Jan 2004 16:15:13 +0000 Francesco wrote:
> On Thu, 8 Jan 2004 12:43:46 +0100
> kirash <ki...@in...> wrote:
> > dato che ti trovi fai lo stesso servizio per DLT_LOOP
> > e DLT_IEEE802_11 in modo da farlo compilare anche sotto NetBSD,
> > anche sotto netbsd con l'interfaccia di loopback lo0
> > non funziona perche' viene vista come DLT_NULL, mentre
> > openbsd la identifica come DLT_LOOP nessuno dei due datalink
> > e' gestito da tcpick...
> 
> ti ringrazio molto per i test, adesso metto tutto cio' nella TODO list.

basta aggiungere queste righe allo switch su datalinkid
nel main() di tcpick.c

***
#ifdef DLT_LOOP
    case DLT_LOOP:
#endif
    case DLT_NULL:
      {
        ip_trasl=4;
        break;
      }
***



-- 
GLS aka KIRASH