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.
