From: Neil McKee (neil_mckee@inmon.com)
Date: 01/17/03
Hello Tim,
You are correct. Well spotted. The non-contiguous mask works when it is
the only one in the list, but fails when a second one is added.
This will be fixed for the 3.0 release. In the mean time the workaround
is to make a separate query for each one (or craft your own filter
string using two "addressMaskEqual" compares instead of one
"addressMaskInList").
(FYI, the problem occurs because a list of subnets is loaded into a
special data structure for rapid searching (important if there are
thousands of subnets). The search is longest-prefix-first and it
assumes contiguous masks. A mask like "255.255.0.255" would be
interpreted as a 32-bit (all 1s) mask because the lsb is 1).
regards,
neil
Tim Durack wrote:
> I have noticed what looks like an anomaly when using non-contiguous bit
> masks for address specifications.
>
> If I write:
>
> destinationAddress=10.1.0.255/255.255.0.255
>
> I get all directed broadcasts in the 10.1.0.0 network.
>
> If I write:
>
> destinationAddress=10.1.0.255/255.255.0.255,10.2.0.255/255.255.0.255
>
> I get no data, even though 10.2.0.0 shows directed broadcasts.
> The filter string looks correct, any ideas why this might happen?
>
> Thanks,
>
> Tim:>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
-- Neil McKee, InMon Corp. tel: +1 (415) 661-6343 http://www.inmon.com
This archive was generated by hypermail 2.1.4 : 01/17/03 PST