|
ULFL wrote:
> Two things remaining :-)
> if zero items are "shown", the tab label should display "Errors: 0" and
> not "Errors:" IMHO that's just more intuitive
No problem, a 2 second fix on this one.
> More important: if you close a capture file, the counts don't go back to
> zero
I will look into this. I had tested a reset and reload but failed to look into the possibility that the user
might just close the file. Shouldn't be too much work to resolve.
> Same idea as mine, but we should keep an eye to not slow down things on
> large capture files ...
One concern I have is the use of redissect_packets instead of retap_packets. I found in my testing
that the expert item isn't actually valid unless a redissect is performed. Perhaps this is just in the
manner that I am storing the pointer to the expert item in the expert tap struct but not sure. I
will do a little more investigation since the retap is less time consuming.
> What I don't want to say is that the tree like display doesn't have it's
> own reasons, so we simply might want to have both and probably keeping
> them in separate dialogs. Just unsure for now and no time to do deep
> thinking ...
You are seeing the expert data in a different way then I am. Not that this view is wrong, but
as you know many people use Ethereal in different ways. I typically look at higher
level protocols then network protocols. So, I am more concerned in actual error
conditions being returned by the upper layers. I want to see the actual error and
the percentage/number included in the trace. Where the error occurred is less important
with the exception of what the request packet was passing. So what I envisioned was that with
the expanded item, the user can click on the packet number and the trace is positioned to the
reply packet containing the error condition (just like the expert infos dialog does).
Then the request packet is easily analyzed as well by the user. (I have the luxury of having
dual monitors and can easily have the expert dialog in one window and the Ethereal main window in the other.)
But I see no reason why we can't support both types of views.
> What's the difference to "Find Frame/Find Frame/Selected"?!? Beside the
> deep menu tree, of course, and beside the fact that it should be called
> "Find Packet/Find Packet/Selected"...
> I suspect that you simply copied this context menu and didn't really
> understand what it's all about. However, you're in a good tradition ...
Yes, the context menu was part of the service response time code and I simply
copied and modified. But there is a big difference here between the two options.
First the Find Frame/Selected is limited in the composite expert table due to the fact
that the expert item may or may not be present. If you were to perform a find frame on
an expert info which originally passed an expert item then the find, find next, and find previous
all work great for moving around in the packet trace. But if the expert info was informational only
and doesn't pass an expert item, then the search is performed by text criteria. Meaning to say, that
the user may or may not find the exact packet that met this expert condition. Depending on how they
modified the search criteria and what portion of Ethereal text data was searched. (IE... Summery, decode, data).
The Go to first occurrence just takes the packet number of the first entry and positions the trace to
that particular packet number. No guessing and guaranteed to be the correct packet matching the
expert info.
Once we have decided on the proper sub-options, (whether to use the suggest [+] or not), will
possibly remove the necessity for this option.
You might ask why this is needed? I also would like for each dissector to be able to pass other informational
items to the expert dialog window. For example, in the chat messages, I have modified the NCP dissector
to pass the Entry ID to Name table. The chat message would be something like. EID == myname.user.com.
The need to position the trace to this packet is very important since this entry is associated to only one
server. Any other server would have a different EID number for the same name. So, the user by clicking
on the chat message and then selecting the Go to first occurrence, the user can now see which server
provided the EID. Just a note, the EID to Name table is not accessible to the user at any level, it is used to
generate column data when packet dissection occurs. I am certain that other dissectors also have data that
could be very valuable when troubleshooting specific protocol errors and conditions that are not easily accessible.
Perhaps the Chat message is not the best for this and we should add another set of messages for protocol specific
table data, etc...
I am open to further ideas and constructive criticism, I feel that the data will only help others to use Ethereal more
effectively.
Thanks for the input and time,
Greg
| 
