Re: strange behavior of rlm_ippool
Daniel Eyholzer [EMAIL PROTECTED] wrote: I am using freeradius 1.0.0-pre3 with rlm_ippool managing the ip addresses for a cisco NAS. I have several address pools with 254 IPs each. When I started the radius 2 days ago, the rlm_ippool_tool showed me the correct number of active IP addresses, but today I saw that the output does not match the number of ip addresses that are active on the cisco. The rlm_ippool_tool shows only about 120 active addresses and there are about 254 active addresses (the pool is full) on the cisco. Strangely it all still seems to work, the radius does not assign the addresses that are active on the cisco, even if they are not listed in the output of the rlm_ippool_tool. If I use the rlm_ippool_tool to show the addresses in one of this pools, which have not the correct number of active addresses displayed, I see that the last line of the output is incomplete. There is only the NAS address and port, but no allocated ip address displayed: ... NAS:192.168.128.12 port:0x643 - ipaddr:192.168.158.131 active:1 cli:0 num:1 NAS:192.168.128.12 port:0x3f4 - ipaddr:192.168.158.124 active:1 cli:0 num:1 NAS:192.168.128.12 port:0x4c8 How can I delete this last incomplete line from the db if there is no ip addresse? Also it does not allocate addresses from this pools anymore, even if there are a lot of unused addresses. It still seems to delete the addresses from users that disconnects. What could be the problem with this db files? Before this behavior occurred I used the rlm_ippool_tool with the -n option to add some entries, could that have corrupted my db files? Thanks, Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: strange behavior of rlm_ippool
On Sat, Jul 24, 2004 at 09:49:32AM +0200, Daniel Eyholzer wrote: Daniel Eyholzer [EMAIL PROTECTED] wrote: I am using freeradius 1.0.0-pre3 with rlm_ippool managing the ip addresses for a cisco NAS. I have several address pools with 254 IPs each. When I started the radius 2 days ago, the rlm_ippool_tool showed me the correct number of active IP addresses, but today I saw that the output does not match the number of ip addresses that are active on the cisco. The rlm_ippool_tool shows only about 120 active addresses and there are about 254 active addresses (the pool is full) on the cisco. Strangely it all still seems to work, the radius does not assign the addresses that are active on the cisco, even if they are not listed in the output of the rlm_ippool_tool. If I use the rlm_ippool_tool to show the addresses in one of this pools, which have not the correct number of active addresses displayed, I see that the last line of the output is incomplete. There is only the NAS address and port, but no allocated ip address displayed: ... NAS:192.168.128.12 port:0x643 - ipaddr:192.168.158.131 active:1 cli:0 num:1 NAS:192.168.128.12 port:0x3f4 - ipaddr:192.168.158.124 active:1 cli:0 num:1 NAS:192.168.128.12 port:0x4c8 How can I delete this last incomplete line from the db if there is no ip addresse? Also it does not allocate addresses from this pools anymore, even if there are a lot of unused addresses. It still seems to delete the addresses from users that disconnects. What could be the problem with this db files? Before this behavior occurred I used the rlm_ippool_tool with the -n option to add some entries, could that have corrupted my db files? I've had issues with using rlm_ippool_tool on ippool DBs that are currently in use, and usually stop the RADIUS server before doing anything, for safety's sake... GDBM DBs depend on the accessor to do all the locking, as I recall, and use an in-memory cache. -- Paul TBBle Hampson, on an alternate email client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: New Opensource project-AAAadmin
Kostas,
Hopefully this is still in the context of freeradius for this list...
See body of message below for responses:
- Original Message -
From: Kostas Kalevras [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 23, 2004 10:24 PM
Subject: Re: New Opensource project-AAAadmin
On Fri, 23 Jul 2004, Gary McKinney wrote:
Hi Kostas,
It's nice to see Dialup_Admin can handle a large operation!
I realize dialup_admin is in the radiusd CVS - I would have thought it
would
have been at least a separate CVS to make allowing others to work with
it
directly and not mess with the radiusd CVS - but I suppose it works the
way
it is...
dialupadmin is completely separate from the freeradius server source. It's
on
it's own directory where users can play with it as much as they like
(provided
they have write cvs access). I don't see a reason for a separate cvs.
Changes or Features that would be nice?
1. You have the New Group section setup to allow both adding a new
group to
the system AND displaying and editing an existing group BUT you have to
go
to the Show Groups section to see the actual group names of existing
groups.
Would it not make more sense to have a display in the New Group section
that
displays existing groups so you don't have to bounce between the two
sections to get the name correct??? If you are using just a few groups
then
most likely you will remember the group names but if you have a fair
number
of groups to handle different situations (IE: Pre-Paid users, PPP users,
Wireless users, etc, etc) it would make life easier for the admin to
work
with the system.
The 'Show Group' button in the New Group page is intended as a path to
move to
the Group Administration page after you 've added a new group. In other
words:
Open 'New Group' - Add Group details - Press 'Create' - Press 'Show
Group' to
immediately go to the corresponding group administration page instead of
having
to insert the group name in the left frame ('Edit Group'). It's only a
shortcat,
nothing more. Though your idea of having a non editable drop down menu
with the
existing groups in the 'New Group' page is quite nice. I 'll look into it.
Yes - having a drop-down menu to select an existing name would be more
intuitive...
2. There currently does not exist any method (other than for NAS
Clients)
to setup the system or make changes to the system other than using a CLI
(command line interface) to make changes... IE: If you want to changes
Hints because of some additional requirement you currently have to
know
how to do so and then use the CLI to perform the task - would it not be
easier for someone to make changes to the system if there were a section
that allowed configuration changes (or initial setups) to the system
1. I personally require dialupadmin to be able to run on any server with
just
php support and radclient, not only on the server where freeradius is
running.
I see your point - if the dialup_admin is running on a different box it gets
a little more complicated to change the configuration files and issue the
restart Had not thought of that since I run both on the same box...
2. The language used in the text files is quite complicated (which means
corresponding pages will need a lot of development and will be equally
complicated) and user configurations are infinite. The pages would
probably be able to only support a small part of those configurations
unless
they became even more complicated. If you follow the list archives there
are
cases were per user patches for the server are required for specific
setups.
Just imagine a similar scenario for dialupadmin!
I had envisioned more of a initial starting point - somelthing to get people
started in the configurations as I noticed in the list archives the same
types of issues in configuring the freeradius system (seems most want to
drop in an go without RTFM first [grin]). I suppose the same thing could be
accomplished by writing HOW-TOs in detail for the different types of
configureation settings...
3. An initial setup means configuring not only freeradius but also other
components (ldap or sql installations etc).
I had only thought for the freeradius configs... the others are outside the
scope of what I had envisioned...
4. You don't require an administrator to run sql queries each time he
wants to
go through the accounting of a user, but you DO require him to be able to
setup
the system. This is server software, i assume a minimal user technical
level.
Hopefully the technical level is such that a person capable of installing an
OS (not Windows) is capable of understanding and implementing freeradius and
dialup_admin [grin]...
I would think things like Realm configurations, SQL configurations, LDAP
configurations, SNMP configurations and so one would be a nice addition
to
the system. It is not hard to have PHP scripts that generate the
required
Re: New Opensource project-AAAadmin
On Sat, 24 Jul 2004, Gary McKinney wrote:
Kostas,
Hopefully this is still in the context of freeradius for this list...
dialupadmin is a part of freeradius so i think it is.
See body of message below for responses:
- Original Message -
From: Kostas Kalevras [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 23, 2004 10:24 PM
Subject: Re: New Opensource project-AAAadmin
On Fri, 23 Jul 2004, Gary McKinney wrote:
Hi Kostas,
It's nice to see Dialup_Admin can handle a large operation!
I realize dialup_admin is in the radiusd CVS - I would have thought it
would
have been at least a separate CVS to make allowing others to work with
it
directly and not mess with the radiusd CVS - but I suppose it works the
way
it is...
dialupadmin is completely separate from the freeradius server source. It's
on
it's own directory where users can play with it as much as they like
(provided
they have write cvs access). I don't see a reason for a separate cvs.
Changes or Features that would be nice?
1. You have the New Group section setup to allow both adding a new
group to
the system AND displaying and editing an existing group BUT you have to
go
to the Show Groups section to see the actual group names of existing
groups.
Would it not make more sense to have a display in the New Group section
that
displays existing groups so you don't have to bounce between the two
sections to get the name correct??? If you are using just a few groups
then
most likely you will remember the group names but if you have a fair
number
of groups to handle different situations (IE: Pre-Paid users, PPP users,
Wireless users, etc, etc) it would make life easier for the admin to
work
with the system.
The 'Show Group' button in the New Group page is intended as a path to
move to
the Group Administration page after you 've added a new group. In other
words:
Open 'New Group' - Add Group details - Press 'Create' - Press 'Show
Group' to
immediately go to the corresponding group administration page instead of
having
to insert the group name in the left frame ('Edit Group'). It's only a
shortcat,
nothing more. Though your idea of having a non editable drop down menu
with the
existing groups in the 'New Group' page is quite nice. I 'll look into it.
Yes - having a drop-down menu to select an existing name would be more
intuitive...
2. There currently does not exist any method (other than for NAS
Clients)
to setup the system or make changes to the system other than using a CLI
(command line interface) to make changes... IE: If you want to changes
Hints because of some additional requirement you currently have to
know
how to do so and then use the CLI to perform the task - would it not be
easier for someone to make changes to the system if there were a section
that allowed configuration changes (or initial setups) to the system
1. I personally require dialupadmin to be able to run on any server with
just
php support and radclient, not only on the server where freeradius is
running.
I see your point - if the dialup_admin is running on a different box it gets
a little more complicated to change the configuration files and issue the
restart Had not thought of that since I run both on the same box...
2. The language used in the text files is quite complicated (which means
corresponding pages will need a lot of development and will be equally
complicated) and user configurations are infinite. The pages would
probably be able to only support a small part of those configurations
unless
they became even more complicated. If you follow the list archives there
are
cases were per user patches for the server are required for specific
setups.
Just imagine a similar scenario for dialupadmin!
I had envisioned more of a initial starting point - somelthing to get people
started in the configurations as I noticed in the list archives the same
types of issues in configuring the freeradius system (seems most want to
drop in an go without RTFM first [grin]). I suppose the same thing could be
accomplished by writing HOW-TOs in detail for the different types of
configureation settings...
In any case any initial connfiguration procedures are more suited for the
freeradius server, not dialupadmin. Though i prefer having complete,detailed
documentation for how the system works, rather than providing initial
configuration scripts. Especially in the case of freeradius i am quite certain
that providing such functionality would just move discussion on the mailing
lists from 'how can i do this?' to 'i want to do that and the install script
does not help. Fix it!'
3. An initial setup means configuring not only freeradius but also other
components (ldap or sql installations etc).
I had only thought for the freeradius configs... the others are outside the
Re[2]: Passing internal attributes between modules
Hello Alan, Good!, can you give-me an example of how to do it ? (I've read doc/aaa.txt, doc/variables.txt and doc/rlm_sql ) All the tests I've done trying to pass information between modules have failed. In which attributes list are they stored ? Is there any way of adding an attribute to the request list ? Thanks. Friday, July 23, 2004, 9:37:36 PM, you wrote: AD PedroRibeiro (B) [EMAIL PROTECTED] wrote: Is there any way of passing values in internal attributes between modules while processing the authorization (set an attribute when process the users file to be used in sql authorization) ? AD Uh, yes. That's how the server works. AD Alan DeKok. AD - AD List info/subscribe/unsubscribe? See AD http://www.freeradius.org/list/users.html -- Best regards, PedroRibeiromailto:[EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re[2]: Passing internal attributes between modules
PedroRibeiro (B) [EMAIL PROTECTED] wrote: All the tests I've done trying to pass information between modules have failed. I don't see why. In which attributes list are they stored ? In whatever list you want. Is there any way of adding an attribute to the request list ? Yes. See the source code for the modules. This is how ALL of the modules work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dialup_admin (was Re: New Opensource project-AAAadmin )
Gary McKinney [EMAIL PROTECTED] wrote: I realize dialup_admin is in the radiusd CVS - I would have thought it would have been at least a separate CVS to make allowing others to work with it directly and not mess with the radiusd CVS - but I suppose it works the way it is... The intent is to distribute it as part of the server, so that people can use it to administer the server. I would think things like Realm configurations, SQL configurations, LDAP configurations, SNMP configurations and so one would be a nice addition to the system. That's probably a longer-term work item. Once Kostas finds time to put a web page on freeradius.org about the project, I expect to see a LOT more interest in it, and a lot more patches. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dialup admin replacement
Hello all, I am looking for a web interface which does what dialup admin does and allows users to access it via there login/password and get all the information they require download limits, what they have downloaded and so on. Anything out there which does that ? Sarky - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
