Re: smb.time || smb2.time is valid in a filter string but not in a custom column field?

[Richard Sharpe <realrichardsharpe () gmail com>]

On Fri, Jun 14, 2013 at 7:05 AM, Jeff Morriss <jeff.morriss.ws () gmail com> wrote:
> On 06/14/13 09:35, Richard Sharpe wrote:
> > On Fri, Jun 14, 2013 at 6:27 AM, Jeff Morriss <jeff.morriss.ws () gmail com> wrote:
> > > On 06/13/13 20:46, Guy Harris wrote:
> > > > On Jun 13, 2013, at 5:16 PM, Richard Sharpe <realrichardsharpe () gmail com>
> > > > wrote:
> > > >
> > > > > I thought I would try to work around my issue with smb.time vs
> > > > > smb2.time by using a custom column field and putting in an expression,
> > > > > but it seems not to work. An expression that is acceptable in the
> > > > > Filter field is not acceptable in a custom column.
> > > > >
> > > > > Why is this?
> > > >
> > > >
> > > > Because "||" is a Boolean "or", not a human-language "or". :-)
> > > >
> > > > I.e., "a || b" is a packet-matching expression that matches if the
> > > > expression "a" matches or the expression "b" matches, not a field expression
> > > > that evaluates to whichever of the fields "a" or "b" is present (with "a"
> > > > chosen if both are present, presumably).
> > > >
> > > > The Filter field takes packet-matching expressions; the custom column
> > > > field takes field names.  Field names are valid packet-matching expressions,
> > > > which match if the field is present in the packet and don't match if it's
> > > > not, but arbitrary packet-matching expressions aren't valid as custom
> > > > columns.
> > > >
> > > > Having a separate feature allowing a set of field names for a custom
> > > > column could be useful.  I'm not sure an "||" operator, given its existing
> > > > meaning in C (and in packet-matching expressions), would be the right syntax
> > > > for that.
> > >
> > >
> > > What would an "or" in the context of columns mean?  In particular in the
> > > case where both fields have a value.
> >
> > Ahhh, the value of discussion.
> >
> > Since each is prefaced by a protocol name, in this case it would never
> > happen. Perhaps it should use short circuit evaluation. The first that
> > exists is the value that is used.
>
> I suppose.  But I live in a world where PDUs are very regularly bundled
> together (often by SCTP's aggressive bundling but these days also by TCP
> because the traffic rate is high enough).  (And the connections in
> question may be carrying different protocols once you get far enough up
> the stack.)
>
> The problem I see with a short-circuit is that you get one answer when
> there are, in fact, two.  We get beat up a fair amount over behaviors
> when PDUs are bundled, we should be careful to avoid adding more.
>
> What about separators?  For example:
>
> smb.time;smb2.time
>
> We could make it smart enough to not print the separator if only one
> field is present (for the common case).  Supporting a set of separators
> (semicolon, comma, and space come to mind) might be useful for different
> types of fields.  That might get ugly if someone wanted to do multiple
> fields with different separators though...

Hmmm, the code already deals with that in some sense. For example, on
compound SMB2 response, two values show up in the field separated by
commas.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe