["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

From: "Jason House"

Subject: [Ethereal-dev] [Patch] revised: tap-tcp_close

Hi,

 

I have checked in a slightly different version of Jason's  packet-tcp.[c|h] support for tapping

TCP.

 

Currently there are no users of the TCP tap.

 

Jason,

your tcp-close tap, to make it more general, is it possible to change your tap and call it

tcp,sessions or something and make it produce something like

one line for each seen tcp session with

src-ip,src-port <-> dst-ip,dst-port   number-of-frames,  number-of-bytes   extra-flags

 

where extra-flags would be like the flags your initial tcp,close produced (how the session was torn down)

 

maybe also with an indication of which side tore it down and possible also number of frames/bytes in

each direction of the session.

That would make it both provide the information you need as in tcp,close but also information that almost

everyone ever looking at tcp sessions could find useful. (regardless if they want to know how the session

was closed or not).

 

You should also provide a patch to tethereal.pod.template or whatever it is called to explain what the

tap listener does and how to parse the output.

 

 

Pavel,

There is now a tap point for the tcp protocol that can be used to generate callbacks for functions that

want information re certain tcp packets.

packet-tcp.h now contains the following definitions:

/* TCP flags */
        #define TH_FIN  0x01
        #define TH_SYN  0x02
        #define TH_RST  0x04
        #define TH_PUSH 0x08
        #define TH_ACK  0x10
        #define TH_URG  0x20
        #define TH_ECN  0x40
        #define TH_CWR  0x80
       
       
        /* the tcp header structure, passed to tap listeners */
        struct tcpheader {
                guint32 th_seq;
                guint32 th_ack;
                guint32 th_seglen;
                guint16 th_win;
                guint16 th_sport;
                guint16 th_dport;
                guint8  th_hlen;
                guint8  th_flags;
        };

 

Does the tcpheader struct contain sufficient information to cover all data that the tcp-stream-analysis

thing need?

If not, what is missing?

 

One way to use this new tap point to extract all tcp-header information for all tcp packets matching

a certain criteria would be something like

 

...

/* callback that collects all data */

int

tcp_sequence_packet(void *globally-unique-identifier, packet_info *pinfo, epan_dissect_t *edt, struct tcpheader *tcph)

{

...   do the tcp sequence stuff

}

...

/* when you want to extract all data to create4 the graph*/

if(  register_tap_listener("tcp", globally-unique-identifier,  "ip.addr==1.2.3.4 && ip.addr==4.3.2.1 && tcp.port==1 && tcp.port==2", NULL, tcp_sequence_packet, NULL) ){

      failure, clean up

}

redissect_packets(&cfile);

remove_tap_listener(globally-unique-identifier);

...

 

 

the third parameter to register_tap_listener() is just a displayfilter and only those packetsd that match the filter

will be passed to the callback tcp_seuqence_packet().

 

would this provide sufficient data for your extension to work with this api?

it would make it completely layer-2 and layer-3 agnostic.

 

it would even make it work automagically for those that run tcp/ip across http-tunnels

 

 

if not, what extra data do you need from the tcp header?

 

 

 

this i think is almost sufficient for my tcp-seq/ack analysis to be converted to a tap-listener.

 

there are other obstacles first before that is possible but one step at a time.

 

 

 

(there are "issues" i dont understand fully before changing the way taps work internally to make them call

all tap-listeners immediately from the tap points such as dissect_tcp() instead of as now where

the tap listeners are only called after all dissectors have returned.

the issues relate to me not understanding what impact this would have on the filtering, i.e.

would there be problems in evaluating the display-filter-lookalike string for the tap listener if we try to evaluate

the filter before all dissectors have completed?   probably.

 

this can be changed later when the issues are understood without affecting the tap listeners.

)

 

best regards

    ronnie sahlberg