> A filter such as "tcp.port == 1" works
> but "tcp.port == 12" does not work anymore.
>
> The first rule integer is a T_VAL_NUMBER_STRING while the second one
> seems to be handled as a T_VAL_UNQUOTED_STRING.
Yup.
"1", in "tcp.port == 1", is matched by the rule with "{minus}?[0-9]+",
but "12" is matched by the rule with
"[A-Za-z0-9\:][A-Za-z0-9\.\_\-\:]+".
Perhaps the rule with "{minus}?[0-9]+" should be moved above the rule
with ""[A-Za-z0-9\:][A-Za-z0-9\.\_\-\:]+", so that something consisting
of decimal digits with, perhaps, a minus sign in front of it is matched
by the first of those, rather than the second - as it begins with a
digit, and contains no ":" or "_" or ".", and contains only "-" as the
first character (if it has one at all), it's not going to be a field
name or a protocol.
Unfortunately, however, it *could* be a host name - my home machine's
host name begins with its IP address, with "-"s replacing "."s, and thus
begins with a digit. (RFC 1035 appears to say that's invalid:
The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case. That is, two names with
the same spelling but different case are to be treated as if identical.
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
although the "the following syntax will result in fewer problems" clause
doesn't make it entirely clear if that's a recommendation or a
requirement - "The labels must follow the rules for ARPANET host names"
may only be saying "*to be valid according to this recommendation* the
labels must follow the rules for ARPANET host names".)
Now, a number by itself is sufficiently unlikely to be a host name that
we can probably get away with interpreting "17" as a number rather than
a host name, so this may not be a problem.
