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
