Guy Harris wrote:
> In addition, it'd be nice to have a tap that requires *no* dissector
> changes, and that just gets handed a protocol tree - or that registers a
> set of fields and gets handed some data structure with the values of
> those fields, if present.
Actually, that's what I initially assumed the tap would be... handling of
filterable fields from the protocol tree.
About the time that the tap stuff was first being proposed, I sent an e-mail
indicating that I had code, that I probably couldn't share, that was based
off information in the protocol tree.
That code revolves around generating summary tables of traffic. At the most
basic level it provides loading summaries by TCP/UDP port and IP protocol...
Summary statistics do that too, but they don't have the ability to do create
histograms of packet sizes or plots of load versus time, etc...
The three tables I just mentioned were:
* ip.proto vrs. ip.len
* udp.theport vrs. ip.len
* tcp.theport vrs. ip.len
I had made .theport instead of just .port or .srcport or .dstport because
none of them quite fit the bill for what I needed to generate the tables.
there is only one udp.theport/tcp.theport for a tcp/udp packet and it
basically is the port that is identified as the proper one for the tcp/udp
session. Basically it is the more recognized port number of the pair. If
neither is recognized udp.dstport or the min of tcp.srcport and
tcp.dstport...for commercial stuff I think that works pretty well...
If the e-mails of the recent past indicate anything, I tend not to explain
things as clearly as I would like... so I'll stop here and see what kind of
reaction I get.
> The combination of the two of those might allow the TCP stream analysis
> to be implemented as a tap, for example (and, as a side effect, no
> longer have to do its own link-layer, IP, and TCP parsing, so that it
> can work atop *any* link-layer protocol).
I've also thought about an enhanced conversations mechanism that is not
restricted to IP protocol/TCP port /UDP port...
Even going as far as being able to open 2 capture files in sequence (or
somehow merging them) and both measuring completion rate as well as showing
packets as complete/incomplete in the packet description. In lossy (aka
wireless) networks, this could be very handy.
> On top of that, it'd be nice to have taps as another type of plugin, in
> addition to the dissector plugins we have now.
I would love to see that happen. In addition, certain tap listeners (such as
those based off the protocol tree) could have personal configuration files
that define which fields in particular are used. table/histogram/plotting
tap listeners could very easily benefit from such a feature.
