On Fri, Apr 07, 2000 at 11:00:02AM -0500, Ashok Narayanan wrote:
>
> >
> > tcp.port == (80 | 8080)
> >
> > Which is shorthand for:
> > tcp.port == 80 || tcp.port == 8080
>
> This is something I am not too sure about. Why should
> tcp.port==(80|8080) not be equivalent to tcp.port==8080? (bitwise OR
> of the port numbers). While for ports I can understand your
> decomposition, a bitwise decomposition is very useful for things like
> flag registers in packets. I'd then make the case that a single
> approach would be good for ports and flags, which leads me towards
> saying that tcp.port==(80|8080) is not the same as tcp.port==80 ||
> tcp.port==8080.
True, I do need to allow bit operations, which means I need to alter my
design a bit more. Because fields can occur more than once in a single
packet, I have to account for multiple field values during a field comparison.
For example,
ip.addr == x
During the processing of the equality test, I account for the multiple occurences
of ip.addr in the packet. But for something like:
ip.addr & 0xff000000 == 192
I need to do a bit more work to handle the multiple values of ip.addr.
Thanks for catching that.
>
> Hmmm... so that's the reason. Well, the other option is not to build
> this knowledge into the grammar, but just to implement the comparison
> operator against DNS domain names to return TRUE if any of the matched
> IP addresses are there. This would require taking more intelligence
> out of the parser and building it into the semantics. However, I
> actually do like your method somewhat - maybe a different operator
> instead of '|'?
True. I'm open to suggestions.
>
> I like the idea - maybe $firewall would be slightly more intuitive for
> Perl programmers. Also, how about not having any disambiguating prefix
Yeah, I like the $ better than the &.
--gilbert