Thanks for the info on the flags_item pointing to the filter data. That is all I needed to move forward.
As for your other comments, This is a change of my original error equivalency feature that I tried to submit a few weeks ago. Guy had replied that it was similar to the expert features submitted by yourself. He suggested that I utilize/interface with your module. Instead of just referring you to the previous thread I will state what this new feature is expected to do.
1. Utilizes the expert tap to acquire the different level messages.
2. Compares the messages and provides a total count for each message.
3. By selecting an entry and right clicking you can perform filtering, finding, colorizing, and searching the internet.
So similar to the expert dialog which gives a packet by packet view, the combined statistics gives the overall view of the different levels of messages. There is a separate tab for each level.
What is it I am trying to accomplish? A higher level view of the expert data. For example, I can easily determine how many TCP connection resets there are in the trace without having to walk through the summary or the expert dialog and count them. Let's say that I wanted to know the total number of HTTP 200 Ok packets in the trace, the combined expert statistics would give me the global count. If let's say I wanted to research what HTTP 200 Ok packets actually mean, then I could right click on the entry and search the internet (Currently default to Google) for the message string. A picture of the combined stats was attached to the original email I sent.
My original thought was to somehow link both the combined expert statistics with your expert statistics. But for now I was just trying to get the overall functionality down. You had mentioned on the expert page, or perhaps in email, about possibly storing the filter data and including such features in the expert data. If I am somehow stepping on your toes, then please tell me to drop what I am doing. My intentions are to add functionality and improve the user experience. If you feel that my efforts are not in the best interest of the project then let me know.
Greg Morris wrote:
> List,
>
> I would like to expand the expert_info_t struct in /epan/expert.h to
> include more data for filtering. I would also like to expand the
> number of parameters passed to expert_add_info_format() to include the
> label of the item to search. For example packet-tcp.c calls
> expert_add_info_format like this...
> expert_add_info_format(pinfo, flags_item, PI_SEQUENCE, PI_NOTE,
> "Retransmission (suspected)");
> I would like to add a parameter to indicate the item to search or
> filter data on. (tcp.analysis.retransmission).
There's no need to, as flags_item points to that information so no
additional parameter is needed.
> I would like to store this inside the expert_info_t struct for later
> use by my combined expert statistics feature so that the user can
> easily filter/colorize/find packets matching the expert condition.
> (similar to functionality in SRT)
Please don't explain by referring to SRT statistics only. There are a
lot of different ways statistics are done, and most people (including
me) doesn't know them all.
>
>
> /** only for internal and display use */
> typedef struct expert_info_s {
> guint32 packet_num;
> int group;
> int severity;
> gchar * protocol;
> gchar * summary;
> gchar * fvalue_label; /* add for filter support */
> } expert_info_t;
> I would also like to modify the expert tap to trap for the value of
> the fvalue label.
"the expert tap to trap for the value of the fvalue label"?!? I didn't
know that we are using traps in Ethereal ...
> I assume that I could make a call to fvalue_() functions to retrieve
> the actual value but we may be better off actually passing the value
> and storing that in the expert_info_t struct as well. Ideas? comments?
>
> Currently my combined expert statistics
what is your combined expert statistics?!?
> will search the internet (google) for the summary string and protocol.
> I would also like to add the ability to search and filter within
> Ethereal. But to do that I need some reference to build the filter
> syntax. If nobody believes this to be a good idea I can drop these
> features.
>
Conclusion:
Sorry, but I just don't really understand what you are talking about. As
I've seen often on this list before, you are trying to describe a
solution. However, you simply forgot to describe the problem which you
are trying to solve. This makes it very hard to understand and even
harder to give any suggestions on this. Some question comes to mind
(probably incomplete):
What is the problem you are trying to solve?
What is the benefit to gain?
Can it currently be solved in a different (but probably inconvenient)
way or not at all?
In which (use-)cases will it be helpful (and in which not)?
What are the steps to use it?
...
Regards, ULFL
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
