From: "Guy Harris"
>On Sep 18, 2003, at 10:55 AM, Greg Morris wrote:
>> The filter is created as
>>
>> ipx.node==043432.000000000001.
>>
>> This is invalid s/b
>>
>> ipx.net==043432 AND ipx.node==00:00:00:00:00:01
>
>Unfortunately, that breaks the current assumption in the conversations
>list code that the filter for a given address is of the form "{field}
>== {value}", i.e. that for all protocols there's a single field
>corresponding to the address.
>
>I see a couple of ways of fixing this:
>
>1) make that assumption true, by adding a possibly-hidden field -
>which would either have to be an FT_BYTES field or a new FT_IPXADDR (or
>FT_IPX) type;
>
>2) have per-address-type routines (or a single routine that takes an
>"address" structure as an argument) that return a filter of the
>appropriate type, and have the conversations list code call it.
I would go for 1, but I would make it FT_STRING
Add three new hf-fields which are of type FT_STRING : ipx.src_addr
ipx.dst_addr ipx.addr
and just use these instead from the conversation thing.
These three fields should be hidden and not show up in the tree pane since
they dont provide any new information that isnt there
already and would basically just be redundant.
However, they would be used in filters created from the Conversation List
(and the new Endpoint List) dialogues
so users which filter on these ipx things alot would learn that they do
exist by looking at what happens when you create filters
from the Conversation List dialogue.
(is there anyone still filtering out conversations manually instead of using
CL to create the filters for them?.
It is quite useful.
For TCP, it even shows you the ports that are used.)
