mailing list archives
Re: smb.time || smb2.time is valid in a filter string but not in a custom column field?
From: Richard Sharpe <realrichardsharpe () gmail com>
Date: Fri, 14 Jun 2013 07:15:56 -0700
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>
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
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
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 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:
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
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe