Bugs found (one of them fixed) in 2.3Stable1

I home this time the message reach their destination ... (I'm reposting
because the last messages i'v sent about this subject haven't recieved any
comments/responses)

BUG#1 (Solved)

I'v detected a bug in 'maxconn' acl, the behaviour was the inverse of the
expected, taking a look at acl.c and client_db.c i'v detected the bug
documented in the fallowing diff.

--- ../squid-2.3.STABLE1/src/acl.c Mon Jan 10 06:10:37 2000
+++ src/acl.c Mon Jan 24 12:18:47 2000
@@ -1374,7 +1374,7 @@
        /* NOTREACHED */
     case ACL_MAXCONN:
        k = clientdbEstablished(checklist->src_addr, 0);
- return ((k > ((intlist *) ae->data)->i) ? 0 : 1);
+ return ((k > ((intlist *) ae->data)->i) ? 1 : 0);
        /* NOTREACHED */
     case ACL_URL_PORT:
        return aclMatchIntegerRange(ae->data, (int) r->port);
----------------------------------------------------------------------------
BUG#2 (Unsolved)

In squid2.3st1

With this acl:
>acl restricted src 10.0.0.128/255.0.0.128 10.85.0.0/16

the address 10.79.17.192 has the access permited in http_access

2000/01/24 18:07:23| aclMatchIp: '10.79.17.192' NOT found

Reversing the order of the parameters:
>acl restricted src 10.85.0.0/16 10.0.0.128/255.0.0.128

2000/01/24 18:09:56| aclMatchIp: '10.79.17.192' found

Adding some debug info i'v detected that in the first case the mask used in
the matching code of the first IP in the list is: 255.255.0.0 instead of
255.0.0.128

I know this aren't trivial masks but an and is an and, that should work
independent from the order of the ip's/masks in the list.

I guess there's some bug in the parser and (in the first case) the mask of
the second parameter is beeing used in the first ??

Best Regards

[]-------------------------------------------------------------[]
  Pedro Ribeiro
  Online: http://www.isel.pt/~pribeiro/
  IRC(PTnet) Nick: PAntMaR
  e-Mail: Personal: pribeiro@isel.pt / Admin: netadmin@isel.pt
  PGP Key Available in keyservers.
  PGPFP: E848 DCA3 5397 97EF 4CF9 2347 24BD BEF8 D104 1743
[]-------------------------------------------------------------[]
Received on Tue Feb 01 2000 - 03:58:18 MST