Compare IP-Adresses with '!=' (BUG?)

[Marco Steinacher]

Hello

I'm trying to reach to following goal:
User in the group 'testgroup' must not be able to connect to the NAS 
with IP '1.2.3.4'.

To do that I added a record to the table radgroupcheck (I'm using MySQL 
for authorisazion):

GroupName: 'testgroup'
Attribute: 'NAS-IP-Address'
Value: '1.2.3.4'
Op:'!='

But this does not work because the values were compared with the 
operator '==', although the operator '!=' was recognized (NO message 
'Invalid operator for item NAS-IP-Address: reverting to '=='' occurs).
So id doesn't matter if I set Op='==' or Op='!='.


Is this a bug?
Does anybody see how I could work around that?
Does anybody know another solution for the goal specified at the top?

Thanks for listening!
Marco
-- 
WebSource Internet Services - www.websource.ch
Kontakt/PGP-Keys: www.websource.ch/kontakt
PGP: 0x0B431D6B - 0BCA FD08 2859 FF1A 4B42 29BD DD91 3A67 0B43 1D6B


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: delete_blocked_requests and Unresponsive child

[Marco Steinacher]

Hi

   Think about it for a second.  It's taking SIXTY SECONDS to
 authenticate a user?  What the heck is going on in your system?

I think the problem is not the authentication process. It occurs after a 
accounting stop request.

The mentioned problem (resident radiusd process with 99% cpu load) seems to 
be caused by dialin users, that use bundled ISDN connections (128k). The 
process uses up to 99% after the user has disconnected (after AcctStop).

I recorded the debug log from radiusd and extracted the following sequence 
that caused such a 99%-process:

req.   action
-
56  Access channel#1
  - response 56
57  AccStart channel#1
  - response 57
58  AccAlive channel#1
  - response 58
59  Access channel#2
  - response 59
60  AccStart channel#2
61  AccAlive channel#2
  - response 61
  - response 60
62  AccStop channel #2
63  AccStop channel #1
  - response 62
64  AccStop channel #1
  - response 64
== WARNING: Unresponsive child (id 2051) for request 61
--

The only problem is the 99%-process that is left over after that sequence. 
Everything else is ok: Both connections were recorded completely by the 
accunting DB, the user could use the service etc.

The sequence above leads to the following questions:
1. Why is there no response to the request 63?
2. Why causes the AccAlive request 61 the warning, that was processed 
successfully?


Any ideas?
Is there a known problem with bundled ISDN connections?

PS: The debug log is available on request.

Thank you
Marco Steinacher
-- 
WebSource Internet Services - www.websource.ch
Kontakt/PGP-Keys: www.websource.ch/kontakt

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html