Re: SQLIPPool performance issue
Hi Roy Thats good news. I am going to change the defaults queries to the ones I sent you. A few questions.. Are you running accounting with your tests or is it all auth? Just an auth test will not be representative. Throw accounting into the mix and it will be worse :-D Depending on the size of your tables and the number of pools it may or may not make sense to actually simplify the indexes. Try the following set instead and see how it performs: CREATE INDEX radippool_poolname ON radippool USING btree (pool_name); CREATE INDEX radippool_framedipaddress ON radippool USING btree (framedipaddress); CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree (nasipaddress, pool_key, framedipaddress); ie. DROP INDEX radippool_poolname_expire; CREATE INDEX radippool_poolname ON radippool USING btree (pool_name); This is because the expiry_time column gets updated (and therefore the index) for EVERY accounting packet. This change will make the IP allocation a little slower but speed up the subsequent accounting queries. Its a good tradeoff I think in real life, but if you are purely benchmarking auth requests you will actually see a negative hit. Again, please get back to me with how it works out. I have both limited time and hardware (and certainly not a huge sun server) for testing here, but am more than happy to help you do so :-) The other thing is, you have a monster Postgresql box, but is it tuned right. Postgresql's default config is very very conservative so you can get orders of magnitude greater performance out of the box simply by increasing cache sizes etc (Both Postgresql and the OS need to be tuned for a box like this) Regards Peter On Thu 26 Jul 2007, Roy Walker wrote: > Ok chaning the indexes definately made some difference. The database load > still went off the charts, but the radius logs were much better with DB > errors connect errors. This still seems horribly slow. > > I can take it down to 2 simultaneous connections on the radclient test and > will still get some IP Allocation FAILED (although way less than I was) > messages in the radius logs. With only 2 simultaneous connections the DB > load hovers around 1 so that seems fine. > > Here is the command I am using to test: /radclient -p 2 -d > /usr/src/freeradius-server-snapshot-20070725/share -f /tmp/radclient-test > 1.1.1.10 auth testing123 Where the radclient-test file has 5000 client > requests seperated by the necessary blank lines. > > I guess I will spend some time tomorrow and enable postgres query logging. > I already have an idea of what I am going to find, there is just an > insane number of queries running per auth request and the subsequent IP > allocation... > > Peter: If you can share any query changes you have, I would be most > appreciative. > > Roy > > > > > From: > [EMAIL PROTECTED] on > behalf of Peter Nixon Sent: Wed 7/25/2007 6:30 PM > To: FreeRadius users mailing list > Subject: Re: SQLIPPool performance issue > > > > Hi Roy > > The default indexes are: > > CREATE INDEX radippool_poolname_ipaadr ON radippool USING btree > (pool_name, framedipaddress); > CREATE INDEX radippool_poolname_expire ON radippool USING btree > (pool_name, expiry_time); > CREATE INDEX radippool_nasipaddr_poolkey ON radippool USING btree > (nasipaddress, pool_key); > CREATE INDEX radippool_nasipaddr_calling ON radippool USING btree > (nasipaddress, callingstationid); > > After reading though them, I think they need some work... (My production > queries are a little different and so are my indexes) > > I think a better index set would be: > > CREATE INDEX radippool_poolname_expire ON radippool USING btree > (pool_name, expiry_time); > CREATE INDEX radippool_framedipaddress ON radippool USING btree > (framedipaddress); > CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree > (nasipaddress, pool_key, framedipaddress); > > Therefore, please run to fullowing on your postgresql database, and report > back to me what difference it makes: > > DROP INDEX radippool_poolname_ipaadr; > DROP INDEX radippool_nasipaddr_poolkey; > DROP INDEX radippool_nasipaddr_calling; > CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree > (nasipaddress, pool_key, framedipaddress); > CREATE INDEX radippool_framedipaddress ON radippool USING btree > (framedipaddress); > > Cheers > > Peter > > On Thu 26 Jul 2007, Roy Walker wrote: > > Using freeradius-server-snapshot-20070705. > > > > I have setup a test scenario where radclient is sending 500 simultaneous > > requests to the radius server. This drives the load on the radius and > > postgres database to pretty much max. The Postgres database is
Re: Op values for Attributes
That's not exactly what I asked but thanks, that's actually a link which I can use. Liran. On 7/25/07, Dennis Skinner <[EMAIL PROTECTED]> wrote: > liran tal wrote: > > Hey everyone, > > > > I was wondering... are the Op values for certain RADIUS attributes will > > always be the same or it is completely dynamic to assign any Op value to > > any attribute. > > > > For example, the Max-All-Session attribute, is it always assigned the := > > op or may > > it be assigned += , =* , != etc... some other Ops. > > The answer was posted 2 hours before your email in another thread: > > http://wiki.freeradius.org/Operators > or > man users > > -- > Dennis Skinner > Systems Administrator > BlueFrog Internet > http://www.bluefrog.com > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: SQLIPPool performance issue
Ok chaning the indexes definately made some difference. The database load still went off the charts, but the radius logs were much better with DB errors connect errors. This still seems horribly slow. I can take it down to 2 simultaneous connections on the radclient test and will still get some IP Allocation FAILED (although way less than I was) messages in the radius logs. With only 2 simultaneous connections the DB load hovers around 1 so that seems fine. Here is the command I am using to test: /radclient -p 2 -d /usr/src/freeradius-server-snapshot-20070725/share -f /tmp/radclient-test 1.1.1.10 auth testing123 Where the radclient-test file has 5000 client requests seperated by the necessary blank lines. I guess I will spend some time tomorrow and enable postgres query logging. I already have an idea of what I am going to find, there is just an insane number of queries running per auth request and the subsequent IP allocation... Peter: If you can share any query changes you have, I would be most appreciative. Roy From: [EMAIL PROTECTED] on behalf of Peter Nixon Sent: Wed 7/25/2007 6:30 PM To: FreeRadius users mailing list Subject: Re: SQLIPPool performance issue Hi Roy The default indexes are: CREATE INDEX radippool_poolname_ipaadr ON radippool USING btree (pool_name, framedipaddress); CREATE INDEX radippool_poolname_expire ON radippool USING btree (pool_name, expiry_time); CREATE INDEX radippool_nasipaddr_poolkey ON radippool USING btree (nasipaddress, pool_key); CREATE INDEX radippool_nasipaddr_calling ON radippool USING btree (nasipaddress, callingstationid); After reading though them, I think they need some work... (My production queries are a little different and so are my indexes) I think a better index set would be: CREATE INDEX radippool_poolname_expire ON radippool USING btree (pool_name, expiry_time); CREATE INDEX radippool_framedipaddress ON radippool USING btree (framedipaddress); CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree (nasipaddress, pool_key, framedipaddress); Therefore, please run to fullowing on your postgresql database, and report back to me what difference it makes: DROP INDEX radippool_poolname_ipaadr; DROP INDEX radippool_nasipaddr_poolkey; DROP INDEX radippool_nasipaddr_calling; CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree (nasipaddress, pool_key, framedipaddress); CREATE INDEX radippool_framedipaddress ON radippool USING btree (framedipaddress); Cheers Peter On Thu 26 Jul 2007, Roy Walker wrote: > Using freeradius-server-snapshot-20070705. > > I have setup a test scenario where radclient is sending 500 simultaneous > requests to the radius server. This drives the load on the radius and > postgres database to pretty much max. The Postgres database is an 8 > Core (4 dual cpu) Sun Opteron with 8g of ram and 3 x 15k SAS drives on > an LSI Megaraid controller. So the database box is a decent machine. > > Here is the indexes on the postgres database: > radius=# \di >List of relations > Schema |Name | Type | Owner | Table > +-+---++--- > public | badusers_incidentdate_idx | index | dialup | badusers > public | badusers_pkey | index | dialup | badusers > public | badusers_username_idx | index | dialup | badusers > public | mtotacct_acctdate_idx | index | dialup | mtotacct > public | mtotacct_nasipaddress_idx | index | dialup | mtotacct > public | mtotacct_pkey | index | dialup | mtotacct > public | mtotacct_username_idx | index | dialup | mtotacct > public | mtotacct_userondate_idx | index | dialup | mtotacct > public | nas_nasname | index | dialup | nas > public | nas_pkey| index | dialup | nas > public | radacct_active_user_idx | index | dialup | radacct > public | radacct_pkey| index | dialup | radacct > public | radacct_start_user_idx | index | dialup | radacct > public | radcheck_pkey | index | dialup | radcheck > public | radcheck_username | index | dialup | radcheck > public | radgroupcheck_groupname | index | dialup | radgroupcheck > public | radgroupcheck_pkey | index | dialup | radgroupcheck > public | radgroupreply_groupname | index | dialup | radgroupreply > public | radgroupreply_pkey | index | dialup | radgroupreply > public | radippool_nasipaddr_calling | index | dialup | radippool > public | radippool_nasipaddr_poolkey | index | dialup | radippool > public | radippool_pkey | index | dialup | radippool > public | radippool_poolname_expire | index | dialup | radippool > public | radippool_poolname_ipaadr
Freeradius + DHCP +vlans ???
Hey guys I am a bit new to the scene and i am having a few problems with configuring freeradius. In essence what i want is that the user, once verified to be assigned to a specific vlan and get an ip address from a dhcp server, which will be aware of the vlans and there for assign different address and subnets to each. Does this scenario make any sense? Will it be the freeradius server that will be notifying the dhcp server to aquire an address for the client? Will the dhcp server then contact the access point to let it know what address the client has been given and it in its turn give it to the client? Or will it be that the access point will contact the dhcp server once it has the reply from the freeradius server, giving it the vlan id/number and requesting an ip address and other info? Is this the right or wrong way of going about this? regards George - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQLIPPool performance issue
Hi Roy The default indexes are: CREATE INDEX radippool_poolname_ipaadr ON radippool USING btree (pool_name, framedipaddress); CREATE INDEX radippool_poolname_expire ON radippool USING btree (pool_name, expiry_time); CREATE INDEX radippool_nasipaddr_poolkey ON radippool USING btree (nasipaddress, pool_key); CREATE INDEX radippool_nasipaddr_calling ON radippool USING btree (nasipaddress, callingstationid); After reading though them, I think they need some work... (My production queries are a little different and so are my indexes) I think a better index set would be: CREATE INDEX radippool_poolname_expire ON radippool USING btree (pool_name, expiry_time); CREATE INDEX radippool_framedipaddress ON radippool USING btree (framedipaddress); CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree (nasipaddress, pool_key, framedipaddress); Therefore, please run to fullowing on your postgresql database, and report back to me what difference it makes: DROP INDEX radippool_poolname_ipaadr; DROP INDEX radippool_nasipaddr_poolkey; DROP INDEX radippool_nasipaddr_calling; CREATE INDEX radippool_nasip_poolkey_ipaddress ON radippool USING btree (nasipaddress, pool_key, framedipaddress); CREATE INDEX radippool_framedipaddress ON radippool USING btree (framedipaddress); Cheers Peter On Thu 26 Jul 2007, Roy Walker wrote: > Using freeradius-server-snapshot-20070705. > > I have setup a test scenario where radclient is sending 500 simultaneous > requests to the radius server. This drives the load on the radius and > postgres database to pretty much max. The Postgres database is an 8 > Core (4 dual cpu) Sun Opteron with 8g of ram and 3 x 15k SAS drives on > an LSI Megaraid controller. So the database box is a decent machine. > > Here is the indexes on the postgres database: > radius=# \di >List of relations > Schema |Name | Type | Owner | Table > +-+---++--- > public | badusers_incidentdate_idx | index | dialup | badusers > public | badusers_pkey | index | dialup | badusers > public | badusers_username_idx | index | dialup | badusers > public | mtotacct_acctdate_idx | index | dialup | mtotacct > public | mtotacct_nasipaddress_idx | index | dialup | mtotacct > public | mtotacct_pkey | index | dialup | mtotacct > public | mtotacct_username_idx | index | dialup | mtotacct > public | mtotacct_userondate_idx | index | dialup | mtotacct > public | nas_nasname | index | dialup | nas > public | nas_pkey| index | dialup | nas > public | radacct_active_user_idx | index | dialup | radacct > public | radacct_pkey| index | dialup | radacct > public | radacct_start_user_idx | index | dialup | radacct > public | radcheck_pkey | index | dialup | radcheck > public | radcheck_username | index | dialup | radcheck > public | radgroupcheck_groupname | index | dialup | radgroupcheck > public | radgroupcheck_pkey | index | dialup | radgroupcheck > public | radgroupreply_groupname | index | dialup | radgroupreply > public | radgroupreply_pkey | index | dialup | radgroupreply > public | radippool_nasipaddr_calling | index | dialup | radippool > public | radippool_nasipaddr_poolkey | index | dialup | radippool > public | radippool_pkey | index | dialup | radippool > public | radippool_poolname_expire | index | dialup | radippool > public | radippool_poolname_ipaadr | index | dialup | radippool > public | radpostauth_pkey| index | dialup | radpostauth > public | radreply_pkey | index | dialup | radreply > public | radreply_username | index | dialup | radreply > public | radusergroup_username | index | dialup | radusergroup > public | totacct_acctdate_idx| index | dialup | totacct > public | totacct_nasipaddress_idx| index | dialup | totacct > public | totacct_nasondate_idx | index | dialup | totacct > public | totacct_pkey| index | dialup | totacct > public | totacct_username_idx| index | dialup | totacct > public | totacct_userondate_idx | index | dialup | totacct > public | userinfo_department_idx | index | dialup | userinfo > public | userinfo_pkey | index | dialup | userinfo > public | userinfo_username_idx | index | dialup | userinfo > (37 rows) > > This seems to be the recommended indexes from what I have seen. I used > the latest schema from CVS. > > I have not setup the database to look and see if one query is killing > the box, but I am going to guess it is just the amount that is doing it. > > If anyone has another idea I would LOVE to hear it! > > Thanks, > Roy > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > s.org] On Beha
RE: SQLIPPool performance issue
I upgraded to 8.2.4 and the performance does not seem to be any different. I guess my next step is to try looking at the query log and see which is the worst. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] s.org] On Behalf Of Kenneth Marshall Sent: Wednesday, July 25, 2007 1:30 PM To: FreeRadius users mailing list Subject: Re: SQLIPPool performance issue Mr. Walker, It sounds as if you need to tune your postgresql installation. By the way, postgresql 8.2.4 will out perform 8.1.9. You should probably turn on query logging and see what the queries are and if they can be optimized. Maybe you are missing an index or two, although you may just have too little I/O capacity. Good luck. Ken On Wed, Jul 25, 2007 at 01:19:04PM -0500, Roy Walker wrote: > I am having a problem with the SQLIPPOOL performance. This is migration > of an existing radius server using flat user files (old server is > running radius 1.1.0). > > > > Running freeradius-server-snapshot-20070705 on a P4 2.8GHZ machine > > Database is Postgres 8.1.9 running on a monstrous Sun Opteron machine. > > > > When radius starts taking requests (it's a lot of requests, about > 500/sec), the load on the radius server spikes to 100 and it eventually > stops taking requests completely. The database is never above 0.05 > load. > > > > I see messages like these in the radius logs: > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696841693 port 0 user 14696841693) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 19723023688 port 0 user 19723023688) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696845996 port 0 user 14696845996) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696846177 port 0 user 14696846177) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696825390 port 0 user 14696825390) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14694415538 port 0 user 14694415538) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696883664 port 0 user 14696883664) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 12149915071 port 0 user 12149915071) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 19728908614 port 0 user 19728908614) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 19723023948 port 0 user 19723023948) > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 102 due to unfinished request 3988 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 62 due to unfinished request 3987 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 116 due to unfinished request 3989 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 121 due to unfinished request 3990 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 26 due to unfinished request 3991 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 105 due to unfinished request 3992 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 74 due to unfinished request 3993 > > Wed
RE: SQLIPPool performance issue
Using freeradius-server-snapshot-20070705. I have setup a test scenario where radclient is sending 500 simultaneous requests to the radius server. This drives the load on the radius and postgres database to pretty much max. The Postgres database is an 8 Core (4 dual cpu) Sun Opteron with 8g of ram and 3 x 15k SAS drives on an LSI Megaraid controller. So the database box is a decent machine. Here is the indexes on the postgres database: radius=# \di List of relations Schema |Name | Type | Owner | Table +-+---++--- public | badusers_incidentdate_idx | index | dialup | badusers public | badusers_pkey | index | dialup | badusers public | badusers_username_idx | index | dialup | badusers public | mtotacct_acctdate_idx | index | dialup | mtotacct public | mtotacct_nasipaddress_idx | index | dialup | mtotacct public | mtotacct_pkey | index | dialup | mtotacct public | mtotacct_username_idx | index | dialup | mtotacct public | mtotacct_userondate_idx | index | dialup | mtotacct public | nas_nasname | index | dialup | nas public | nas_pkey| index | dialup | nas public | radacct_active_user_idx | index | dialup | radacct public | radacct_pkey| index | dialup | radacct public | radacct_start_user_idx | index | dialup | radacct public | radcheck_pkey | index | dialup | radcheck public | radcheck_username | index | dialup | radcheck public | radgroupcheck_groupname | index | dialup | radgroupcheck public | radgroupcheck_pkey | index | dialup | radgroupcheck public | radgroupreply_groupname | index | dialup | radgroupreply public | radgroupreply_pkey | index | dialup | radgroupreply public | radippool_nasipaddr_calling | index | dialup | radippool public | radippool_nasipaddr_poolkey | index | dialup | radippool public | radippool_pkey | index | dialup | radippool public | radippool_poolname_expire | index | dialup | radippool public | radippool_poolname_ipaadr | index | dialup | radippool public | radpostauth_pkey| index | dialup | radpostauth public | radreply_pkey | index | dialup | radreply public | radreply_username | index | dialup | radreply public | radusergroup_username | index | dialup | radusergroup public | totacct_acctdate_idx| index | dialup | totacct public | totacct_nasipaddress_idx| index | dialup | totacct public | totacct_nasondate_idx | index | dialup | totacct public | totacct_pkey| index | dialup | totacct public | totacct_username_idx| index | dialup | totacct public | totacct_userondate_idx | index | dialup | totacct public | userinfo_department_idx | index | dialup | userinfo public | userinfo_pkey | index | dialup | userinfo public | userinfo_username_idx | index | dialup | userinfo (37 rows) This seems to be the recommended indexes from what I have seen. I used the latest schema from CVS. I have not setup the database to look and see if one query is killing the box, but I am going to guess it is just the amount that is doing it. If anyone has another idea I would LOVE to hear it! Thanks, Roy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] s.org] On Behalf Of Peter Nixon Sent: Wednesday, July 25, 2007 5:21 PM To: FreeRadius users mailing list Subject: Re: SQLIPPool performance issue On Wed 25 Jul 2007, Roy Walker wrote: > I am having a problem with the SQLIPPOOL performance. This is migration > of an existing radius server using flat user files (old server is > running radius 1.1.0). Hi Roy You don't specify which version of FreeRADIUS you are using.. Which is it? What does you your radipool table and indexes look like? Regards -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQLIPPool performance issue
On Wed 25 Jul 2007, Roy Walker wrote: > I am having a problem with the SQLIPPOOL performance. This is migration > of an existing radius server using flat user files (old server is > running radius 1.1.0). Hi Roy You don't specify which version of FreeRADIUS you are using.. Which is it? What does you your radipool table and indexes look like? Regards -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Op values for Attributes
liran tal wrote: > Hey everyone, > > I was wondering... are the Op values for certain RADIUS attributes will > always be the same or it is completely dynamic to assign any Op value to > any attribute. > > For example, the Max-All-Session attribute, is it always assigned the := > op or may > it be assigned += , =* , != etc... some other Ops. The answer was posted 2 hours before your email in another thread: http://wiki.freeradius.org/Operators or man users -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FreeRADIUS 1.1.7 has been released
Feature improvements * Updated LDAP documentation * Added note on DH parameters in eap.conf, and debugging messages which complain if DH is used, but not configured properly. * Updated the Mikrotik dictionary. Added a note that the sample dictionary they supply is broken. * Output more information on blocked threads, which should help narrow down which modules is causing the problem. * Added more eDirectory support. * rlm_ldap now prints out attributes in the standard format * Enabled server-side handling of procedures in MySQL Bug fixes * Added NT-Hash support for mschap_xlat * Corrected documentation to point to correct location of files * Checks for more recent FreeBSD versions * use -DLDAP_DEPRECATED to avoid OpenLDAP crashes * Use correct value for authentication name in rlm_mschap * Fix over-ride for usernames when use_tunneled_reply = yes Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQLIPPool performance issue
Mr. Walker, It sounds as if you need to tune your postgresql installation. By the way, postgresql 8.2.4 will out perform 8.1.9. You should probably turn on query logging and see what the queries are and if they can be optimized. Maybe you are missing an index or two, although you may just have too little I/O capacity. Good luck. Ken On Wed, Jul 25, 2007 at 01:19:04PM -0500, Roy Walker wrote: > I am having a problem with the SQLIPPOOL performance. This is migration > of an existing radius server using flat user files (old server is > running radius 1.1.0). > > > > Running freeradius-server-snapshot-20070705 on a P4 2.8GHZ machine > > Database is Postgres 8.1.9 running on a monstrous Sun Opteron machine. > > > > When radius starts taking requests (it's a lot of requests, about > 500/sec), the load on the radius server spikes to 100 and it eventually > stops taking requests completely. The database is never above 0.05 > load. > > > > I see messages like these in the radius logs: > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696841693 port 0 user 14696841693) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 19723023688 port 0 user 19723023688) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696845996 port 0 user 14696845996) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696846177 port 0 user 14696846177) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696825390 port 0 user 14696825390) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14694415538 port 0 user 14694415538) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 14696883664 port 0 user 14696883664) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 12149915071 port 0 user 12149915071) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 19728908614 port 0 user 19728908614) > > Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool > (did slogic.t-mobile.com cli 19723023948 port 0 user 19723023948) > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 102 due to unfinished request 3988 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 62 due to unfinished request 3987 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 116 due to unfinished request 3989 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 121 due to unfinished request 3990 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 26 due to unfinished request 3991 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 105 due to unfinished request 3992 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 74 due to unfinished request 3993 > > Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from > client nas01 port 1812 - ID: 29 due to unfinished request 3994 > > Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles > to use! skipped 0, tried to connect 0 > > Wed Jul 25 10:29:15 2007 : Auth: Login OK: [12146063348] (from client > nas01 port 0 cli 12146063348) > > > > I have tried playing with
Op values for Attributes
Hey everyone, I was wondering... are the Op values for certain RADIUS attributes will always be the same or it is completely dynamic to assign any Op value to any attribute. For example, the Max-All-Session attribute, is it always assigned the := op or may it be assigned += , =* , != etc... some other Ops. Thanks, Lir. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
SQLIPPool performance issue
I am having a problem with the SQLIPPOOL performance. This is migration of an existing radius server using flat user files (old server is running radius 1.1.0). Running freeradius-server-snapshot-20070705 on a P4 2.8GHZ machine Database is Postgres 8.1.9 running on a monstrous Sun Opteron machine. When radius starts taking requests (it's a lot of requests, about 500/sec), the load on the radius server spikes to 100 and it eventually stops taking requests completely. The database is never above 0.05 load. I see messages like these in the radius logs: Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 14696841693 port 0 user 14696841693) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 19723023688 port 0 user 19723023688) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 14696845996 port 0 user 14696845996) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 14696846177 port 0 user 14696846177) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 14696825390 port 0 user 14696825390) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 14694415538 port 0 user 14694415538) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 14696883664 port 0 user 14696883664) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 12149915071 port 0 user 12149915071) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 19728908614 port 0 user 19728908614) Wed Jul 25 10:29:15 2007 : Info: IP Allocation FAILED from general_pool (did slogic.t-mobile.com cli 19723023948 port 0 user 19723023948) Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 102 due to unfinished request 3988 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 62 due to unfinished request 3987 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 116 due to unfinished request 3989 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 121 due to unfinished request 3990 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 26 due to unfinished request 3991 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 105 due to unfinished request 3992 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 74 due to unfinished request 3993 Wed Jul 25 10:29:15 2007 : Error: Discarding duplicate request from client nas01 port 1812 - ID: 29 due to unfinished request 3994 Wed Jul 25 10:29:15 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Wed Jul 25 10:29:15 2007 : Auth: Login OK: [12146063348] (from client nas01 port 0 cli 12146063348) I have tried playing with the numbers of threads (I used the current radius servers setting to start) and the results are the same. Anyone have any ideas? Thanks, Roy - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Invalid Operator
On Wed 25 Jul 2007, Chris Bell wrote: > They are using the '=' operator. Whether they are correct or not is what > I'm trying to determine :). Maybe I should say that I'm very new to both > Linux and Radius. I've searched the web for references to these errors > but have found nothing that clearly states what should be used. '==' or > '='. http://wiki.freeradius.org/Operators -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Invalid Operator
Chris Bell wrote: > They are using the '=' operator. Whether they are correct or not is what > I'm trying to determine :). Maybe I should say that I'm very new to both > Linux and Radius. I've searched the web for references to these errors but > have found nothing that clearly states what should be used. '==' or '='. $ man users Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE:Invalid Operator
They are using the '=' operator. Whether they are correct or not is what I'm trying to determine :). Maybe I should say that I'm very new to both Linux and Radius. I've searched the web for references to these errors but have found nothing that clearly states what should be used. '==' or '='. Thanks for your patience. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alan DeKok Sent: Tuesday, July 24, 2007 7:02 PM To: FreeRadius users mailing list Subject: Re: rlm_sql bug in 64-bit architecture ? Chris Bell wrote: > Invalid operator for item User-name: reverting to '==' > > All three of my server logs are filled with them and I've been unable to > find the reason why. All the username's listed in the huntgroup can > successfully authenticate. Have you looked at all of your references to User-Name in the configurations? What operator are they using? Is the operator correct? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
Thanks, that makes everything much clearer now :-)
Cheers,
Z2L
- Original Message -
From: "Peter Nixon" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], "FreeRadius users mailing list"
Sent: Wednesday, July 25, 2007 6:17:14 PM (GMT+0200) Asia/Jerusalem
Subject: Re: rml_perl question
On Wed 25 Jul 2007, FreeRadius-ML wrote:
> Hi Peter,
>
> Thanks, that was the missing part for me - I think. Just let me verify
> that I got you correctly:
>
> 1. My OpenSER will send a request to FreeRadius including the full
> digest information.
> 2. Once the request in intercepted by FreeRadius, my
> rlm_perl will simply need to ask the TCP server for the password of the
> user.
yes.
> 3. Once that password had been retrieved, I'll simply set the
> RAD_REPLY{'Cleartext-ssword'} to the password that was retrieved from the
> TCP server.
No. It needs to be RAD_CHECK{'Cleartext-Password'}
> 4. Once the rlm_perl script returns with the OK setting, the rest will
> be handled by the digest module.
Yes. Thats what we have been telling you :-)
> Have I got it right this time? sorry for being a bit of a pain.
With the exception of Cleartext-Password being a CHECK item and not a REPLY
item, yes, you are correct.
--
Peter Nixon
http://peternixon.net/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
On Wed 25 Jul 2007, FreeRadius-ML wrote:
> Hi Peter,
>
> Thanks, that was the missing part for me - I think. Just let me verify
> that I got you correctly:
>
> 1. My OpenSER will send a request to FreeRadius including the full
> digest information.
> 2. Once the request in intercepted by FreeRadius, my
> rlm_perl will simply need to ask the TCP server for the password of the
> user.
yes.
> 3. Once that password had been retrieved, I'll simply set the
> RAD_REPLY{'Cleartext-ssword'} to the password that was retrieved from the
> TCP server.
No. It needs to be RAD_CHECK{'Cleartext-Password'}
> 4. Once the rlm_perl script returns with the OK setting, the rest will
> be handled by the digest module.
Yes. Thats what we have been telling you :-)
> Have I got it right this time? sorry for being a bit of a pain.
With the exception of Cleartext-Password being a CHECK item and not a REPLY
item, yes, you are correct.
--
Peter Nixon
http://peternixon.net/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help: Adding WiMAX VSA support
Govardhana K N wrote: > Thanks Alan, I am working on it. > > Also some attributes also has sub TLV's how can I add them? Do I have to > change any structures? You'll have to change some structures. It involves some "careful" changes to the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Help: Adding WiMAX VSA support
Thanks Alan, I am working on it. Also some attributes also has sub TLV's how can I add them? Do I have to change any structures? Thanks & Regards, Govardhana K N On 7/25/07, Alan DeKok <[EMAIL PROTECTED]> wrote: Govardhana K N wrote: > Hi, > > I am using WiMAX supported client, so the attribute format for WiMAX > is like Attribute-Type, Length, CONTINUATION, and Value. > > How can I modify the server to send the attributes in this format? Edit src/lib/radius.c. That's the code that does packing / unpacking of all RADIUS attributes. The "continuation" field will cause additional complications. The TLV's inside of TLV's will also cause additional complications. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- With Regards, Govardhana K N - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
Hi Peter,
Thanks, that was the missing part for me - I think. Just let me verify that I
got you correctly:
1. My OpenSER will send a request to FreeRadius including the full digest
information.
2. Once the request in intercepted by FreeRadius, my rlm_perl will simply
need to ask the
TCP server for the password of the user.
3. Once that password had been retrieved, I'll simply set the
RAD_REPLY{'Cleartext-ssword'}
to the password that was retrieved from the TCP server.
4. Once the rlm_perl script returns with the OK setting, the rest will be
handled by the
digest module.
Have I got it right this time? sorry for being a bit of a pain.
Z2L
- Original Message -
From: "Peter Nixon" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], "FreeRadius users mailing list"
Sent: Wednesday, July 25, 2007 5:05:02 PM (GMT+0200) Asia/Jerusalem
Subject: Re: rml_perl question
Several people have already told you this, but I am going to have another go
at it.
You want to do Digest Authentication. That great. FreeRADIUS knows how to do
it. All you have to do is supply the Cleartext-Password.
You tell us that you have some propriatary system which holds your passwords
that you need to access over a TCP socket. Great. Feel free to do so.
Basically you need to:
a) Have the digest module enabled in the _authorize_ AND _authenticate_
sections of radiusd.conf
b) Get the password from your backend using perl and return it to FreeRADIUS
in the _authorize_ section as:
PaCleartext-ssword := "yoursupersecretpassword"
This is ALL you should have to do! Do not do anything else! Please. Just
dont!
Cheers
Peter
On Wed 25 Jul 2007, FreeRadius-ML wrote:
> Ok,
>
> What I'm trying to do is have FreeRadius perform its AAA functions again
> a PERL based backend, which reads the user information from a proprietary
> system - via a TCP interface.
>
> The authorization section and the authenticate section both have PERL
> enabled in them.
>
> (I removed the remarks for easier reading) - the first digest is
> commented, but right after perl there is another one.
> -- SNIP
> authorize {
> preprocess
> auth_log
> # attr_filter
> # chap
> # mschap
> # digest
> # IPASS
> # suffix
> # ntdomain
> # eap
> # files
> digest
> perl
> # sql
> # etc_smbpasswd
> # ldap
> # daily
> # checkval
> # pap
> }
> ---
> You are correct in regards to the authentication section (see below), I
> missed that one: - SNIP
> authenticate {
> # Auth-Type PAP {
> #
> # pap
> #
> # }
> # Auth-Type CHAP {
> #
> # chap
> #
> # }
> # Auth-Type MS-CHAP {
> #
> # mschap
> #
> # }
> # digest
> # pam
> unix
> # Auth-Type LDAP {
> #
> # ldap
> #
> # }
> # eap
> perl
> }
> ---
>
> I may be going about it all wrong, which I'm not ruling out. If you have
> something specific to point me at, please do.
>
> Regards,
> Z2L
> - Original Message -
> From: "A L M Buxey" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], "FreeRadius users mailing list"
> Sent: Wednesday, July 25, 2007
> 2:12:55 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
>
> Hi,
>
> you dont have perl enabled in the authorise section of your config...you
> dont have digest enabled in your authorise or authenticate sections
> either. what are you trying to acheive?
--
Peter Nixon
http://peternixon.net/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help: Adding WiMAX VSA support
Govardhana K N wrote: > Hi, > > I am using WiMAX supported client, so the attribute format for WiMAX > is like Attribute-Type, Length, CONTINUATION, and Value. > > How can I modify the server to send the attributes in this format? Edit src/lib/radius.c. That's the code that does packing / unpacking of all RADIUS attributes. The "continuation" field will cause additional complications. The TLV's inside of TLV's will also cause additional complications. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Help: Adding WiMAX VSA support
Hi, I am using WiMAX supported client, so the attribute format for WiMAX is like Attribute-Type, Length, CONTINUATION, and Value. How can I modify the server to send the attributes in this format? Thanks & Regards, Govardhana K N -- With Regards, Govardhana K N - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Support for WiMAX VSA
Hi All, Is the patch file WiMAX VSA support uploaded in FreeRadius? If Yes, How can I get the file? Thanks & Regards, Govardahna K N On 7/19/07, Alan DeKok <[EMAIL PROTECTED]> wrote: Nitin Naveen wrote: > Hi I am Nitin Naveen working with HUGHES SYSTIQUE. We have been working to > enhance freeradius to support WiMAX VSA (as per WiMAX NWG forum). WiMAX > VSA are not the typical type-length-value rather they have > type-length-controlinfo-value. Yes.. > We have enhanced the dictionary but we were not able to generate the > attributes > as per the WiMAX NWG format. For now we have developed our own > rlm_hsc_wimax > module. We like to contribute to freeradius so that the WiMAX VSA are > supported as > part of the standard distribution. To this end we can share our code. > But before that > we would like to follow the correct procedure for releasing the code. Submit a feature request on bugs.freeradius.org. Add the patch as an attachment. Make sure that the code has the GPL license in it. The FreeRADIUS code currently does this. Copyright can remain with you. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- With Regards, Govardhana K N - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
Several people have already told you this, but I am going to have another go
at it.
You want to do Digest Authentication. That great. FreeRADIUS knows how to do
it. All you have to do is supply the Cleartext-Password.
You tell us that you have some propriatary system which holds your passwords
that you need to access over a TCP socket. Great. Feel free to do so.
Basically you need to:
a) Have the digest module enabled in the _authorize_ AND _authenticate_
sections of radiusd.conf
b) Get the password from your backend using perl and return it to FreeRADIUS
in the _authorize_ section as:
Cleartext-Password := "yoursupersecretpassword"
This is ALL you should have to do! Do not do anything else! Please. Just
dont!
Cheers
Peter
On Wed 25 Jul 2007, FreeRadius-ML wrote:
> Ok,
>
> What I'm trying to do is have FreeRadius perform its AAA functions again
> a PERL based backend, which reads the user information from a proprietary
> system - via a TCP interface.
>
> The authorization section and the authenticate section both have PERL
> enabled in them.
>
> (I removed the remarks for easier reading) - the first digest is
> commented, but right after perl there is another one.
> -- SNIP
> authorize {
> preprocess
> auth_log
> # attr_filter
> # chap
> # mschap
> # digest
> # IPASS
> # suffix
> # ntdomain
> # eap
> # files
> digest
> perl
> # sql
> # etc_smbpasswd
> # ldap
> # daily
> # checkval
> # pap
> }
> ---
> You are correct in regards to the authentication section (see below), I
> missed that one: - SNIP
> authenticate {
> # Auth-Type PAP {
> #
> # pap
> #
> # }
> # Auth-Type CHAP {
> #
> # chap
> #
> # }
> # Auth-Type MS-CHAP {
> #
> # mschap
> #
> # }
> # digest
> # pam
> unix
> # Auth-Type LDAP {
> #
> # ldap
> #
> # }
> # eap
> perl
> }
> ---
>
> I may be going about it all wrong, which I'm not ruling out. If you have
> something specific to point me at, please do.
>
> Regards,
> Z2L
> - Original Message -
> From: "A L M Buxey" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], "FreeRadius users mailing list"
> Sent: Wednesday, July 25, 2007
> 2:12:55 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
>
> Hi,
>
> you dont have perl enabled in the authorise section of your config...you
> dont have digest enabled in your authorise or authenticate sections
> either. what are you trying to acheive?
--
Peter Nixon
http://peternixon.net/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
FreeRadius-ML wrote:
> Of course I updated the PERL script. I simply modified the debug function
> to be:
And you did NOT add $RAD_CHECK{Cleartext-Password} = "..." as you were
instructed to do.
> I hadn't set Auth-Type in radiusd.conf, according to references I've
> recieved,
> the only Auth-Type directive I've added in the users.conf file.
Which you were instructed to NOT do.
...
> rlm_digest: Adding Auth-Type = DIGEST
...
> auth: No authenticate method (Auth-Type) configuration found for the request:
> Rejecting the user
You did NOT configure the "digest" module in the "authenticate"
section, as you were instructed to do.
> Alan, i'm asking these questions as I want to understand the possibilities
> and
> the various options that exist.
No. If you wanted to understand, you would follow instructions, and
observe that the instructions worked.
> My only problem here is that I'm now playing around with rlm_perl, which
> appears to
> be a bit more complex in the way it does things.
No, it's not. You set the value of an attribute via the method you
were instructed to use.. That's the *only* complex thing in rlm_perl.
> For example, I've looked into the
> documentation, I hadn't seen any document explaining the information transfer
> between
> the rlm_perl script and the digest mechanism.
I explained this. You seem to have ignored it. You set the value of
the attribute in rlm_perl as you were instructed. The server takes care
of the rest.
> The documentation describes how to work
> with rlm_perl, how to write your own script and so on. But that little piece
> of
> information is missing from it.
doc/aaa.txt explains it. I have told you on this list how it works.
> The general information in the documentation is much
> better than in most OSS projects I know, however, the lack of examples and
> the fact
> that most people tend to work with some form of SQL/LDAP backend, makes any
> other
> usage beyond that a bit more complicated for the novice FreeRadius user.
You are making it difficult for yourself by not following the
instructions on this list.
> Alan, just to make something clear, I think FreeRadius is a wonderful tool.
> I've used
> it in conjunction with GnuGK to build a multi-million minute H323 routing
> switch back in
> 2003, which is still working till today (switching over 25 million minutes a
> month). I've
> used in conjunction with Cisco Access Servers to create various Dial-IN PPP
> access routers,
> and I've used it as a backend for Cisco L2TP/PPTP services, which were all
> working off of
> MySQL, and work to this day - in other words, I know my way around FreeRadius
> fairly well.
Then I don't understand why it's so difficult to get this working.
> The first time I ran into a situation I actually needed to talk to someone on
> the list is
> now. I'm currently in the process of writing a document explaining my
> findings, and maybe
> also help others use rlm_perl, but you have to understand that while I may
> seem a little
> nagging, it is purely due to my Israeli nature that tends to get the better
> of me - and
> my general desire to understand what I'm doing.
I've seen that before. You think there's some secret magical complex
sauce that makes it all work. There isn't. The explanation is simple,
and you've been given it multiple times.
Because you think there's some secret magic sauce, you find it
impossible to believe the simple explanations. Therefore, you don't
follow the instructions on this list, because they cannot possibly be
correct.
I have told you multiple times how to get this to work. It is
abundantly clear that you have great difficulty following instructions.
The Perl script you posted contains *zero* references to
Cleartext-Password, despite the explicit instructions to set it. The
radiusd.conf file will not do digest authentication, despite
instructions here *and* in the comments in radiusd.conf saying how to
get it to work.
Good luck solving your problem.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
Ok,
What I'm trying to do is have FreeRadius perform its AAA functions again a
PERL based
backend, which reads the user information from a proprietary system - via a TCP
interface.
The authorization section and the authenticate section both have PERL enabled
in them.
(I removed the remarks for easier reading) - the first digest is commented, but
right after
perl there is another one.
-- SNIP
authorize {
preprocess
auth_log
# attr_filter
# chap
# mschap
# digest
# IPASS
# suffix
# ntdomain
# eap
# files
digest
perl
# sql
# etc_smbpasswd
# ldap
# daily
# checkval
# pap
}
---
You are correct in regards to the authentication section (see below), I missed
that one:
- SNIP
authenticate {
# Auth-Type PAP {
#
# pap
#
# }
# Auth-Type CHAP {
#
# chap
#
# }
# Auth-Type MS-CHAP {
#
# mschap
#
# }
# digest
# pam
unix
# Auth-Type LDAP {
#
# ldap
#
# }
# eap
perl
}
---
I may be going about it all wrong, which I'm not ruling out. If you have
something specific
to point me at, please do.
Regards,
Z2L
- Original Message -
From: "A L M Buxey" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], "FreeRadius users mailing list"
Sent: Wednesday, July 25, 2007 2:12:55 PM (GMT+0200) Asia/Jerusalem
Subject: Re: rml_perl question
Hi,
you dont have perl enabled in the authorise section of your config...you
dont have digest enabled in your authorise or authenticate sections
either. what are you trying to acheive?
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
mschap:User-Name and DOM\user versus [EMAIL PROTECTED]
All,
A few facts first;
Windows seems to "know" about both DOM\user and [EMAIL PROTECTED]
formats for usernames; when generating an mschap response, it only ever
user the "user" portion.
ntlm_auth seems to take *exactly* what you put into the command line;
that is, it does NO stripping of DOM\user or [EMAIL PROTECTED]
rlm_mschap registers several expansions, including mschap:User-Name -
this particular expansion performs the following transforms:
host/name.dom.example.org -> name$
DOM\user -> user
I'm wondering if it would be sensible to add the following transform to
the above list:
[EMAIL PROTECTED] -> user
The rationale being thus: if you want to support both prefix and suffix
forms of the realm *and* machine based auth, you have to use the
slightly non-intuitive syntax:
ntlm_auth --username=%{Stripped-User-Name:-%{mschap:User-Name}}
and have :
modules {
realm suffix {
format = suffix
delimiter = "@"
ignore_null = yes
}
realm ntdomain {
format = prefix
delimiter = "\"
ignore_null = yes
}
}
authorize {
preprocess
prefix
suffix
mschap
}
If the @suffix transform were in mschap, it would be possible to
dispense with the realm modules entirely, and just use:
ntlm_auth --username=%{mschap:User-Name}
Comments?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
Hi, you dont have perl enabled in the authorise section of your config...you dont have digest enabled in your authorise or authenticate sections either. what are you trying to acheive? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to capture wireless EAP packets on Windows XP?
On 7/25/07, Josh Howlett <[EMAIL PROTECTED]> wrote: > I usually find it simplest to use tcpdump on the RADIUS server, although > I've used Wireshark in the past on Windows supplicants. then there's the NDIS interface problem. Most windows drivers have problems at capturing in promisc and none will support monitor mode. So if it hasn't been tried yet, I suggest trying a capture with promiscuous mode disabled on the supplicant side.. if you want to compare it against the the radiusd side. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
Hi Alan,
Of course I updated the PERL script. I simply modified the debug function to
be:
sub log_request_attributes {
# This shouldn't be done in production environments!
# This is only meant for debugging!
for (keys %RAD_REQUEST) {
&radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}");
}
for (keys %RAD_CHECK) {
&radiusd::radlog(1, "RAD_CHECK: $_ = $RAD_CHECK{$_}");
}
for (keys %RAD_REPLY) {
&radiusd::radlog(1, "RAD_REPLY: $_ = $RAD_REPLY{$_}");
}
}
I hadn't set Auth-Type in radiusd.conf, according to references I've recieved,
the only Auth-Type directive I've added in the users.conf file.
Just for checking, I've removed the directive from the users.conf file, and
now
I'm getting the following in the debug:
rad_recv: Access-Request packet from host 192.168.2.80:43824, id=122, length=194
User-Name = "[EMAIL PROTECTED]"
Digest-Attributes = 0x0a05313031
Digest-Attributes = 0x010e3139322e3136382e322e3830
Digest-Attributes =
0x022a3436613035303339383265646636633663306537373037353165383536346266646632346562
Digest-Attributes = 0x04127369703a3139322e3136382e322e3830
Digest-Attributes = 0x030a5245474953544552
Digest-Response = "897c22eebf92577a23d3d2e91a360d67"
Service-Type = IAPP-Register
Sip-Uri-User = "101"
NAS-Port = 5060
NAS-IP-Address = 192.168.2.80
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 8
modcall[authorize]: module "preprocess" returns ok for request 8
radius_xlat:
'/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070720'
rlm_detail:
/usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
expands to
/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070720
modcall[authorize]: module "auth_log" returns ok for request 8
rlm_digest: Adding Auth-Type = DIGEST
modcall[authorize]: module "digest" returns ok for request 8
perl_pool: item 0xa587328 asigned new request. Handled so far: 1
found interpetator at address 0xa587328
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80
rlm_perl: RAD_REQUEST: Digest-Response = 897c22eebf92577a23d3d2e91a360d67
rlm_perl: RAD_REQUEST: User-Name = [EMAIL PROTECTED]
rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register
rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80
rlm_perl: RAD_REQUEST: NAS-Port = 5060
rlm_perl: RAD_REQUEST: Sip-Uri-User = 101
rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0xa64592c)
perl_pool total/active/spare [32/0/32]
Unreserve perl at address 0xa587328
modcall[authorize]: module "perl" returns ok for request 8
modcall: leaving group authorize (returns ok) for request 8
auth: No authenticate method (Auth-Type) configuration found for the request:
Rejecting the user
auth: Failed to validate the user.
Login incorrect: [EMAIL PROTECTED]/] (from client
192.168.2.80 port 5060)
Delaying request 8 for 1 seconds
Finished request 8
Going to the next request
Cleaning up request 7 ID 121 with timestamp 46a03e12
As a reference, I'm uploading my configuration files to pastebin.com,
according to the following:
radiusd.conf - http://pastebin.com/f31b5226b
rlm_perl.pl - http://pastebin.com/f15f198ca
users.conf - Everything is commented in, which means basically an empty file
Alan, i'm asking these questions as I want to understand the possibilities and
the various options that exist. I'm fully aware of the configuration of Digest
and
how to make digest work with a MySQL backend, that worked without a problem and
I
was able to understand how to start playing around with it to make do what I
want
it to do.
My only problem here is that I'm now playing around with rlm_perl, which
appears to
be a bit more complex in the way it does things. For example, I've looked into
the
documentation, I hadn't seen any document explaining the information transfer
between
the rlm_perl script and the digest mechanism. The documentation describes how
to work
with rlm_perl, how to write your own script and so on. But that little piece of
information is missing from it. The general information in the documentation is
much
better than in most OSS projects I know, however, the lack of examples and the
fact
that most people tend to work with some form of SQL/LDAP backend, makes any
other
usage beyond that a bit more complicated for the novice FreeRadius user.
Alan, just to make something clear, I think FreeRadius is a wonderful tool.
I've used
it in conjunction with GnuGK to build a multi-million minute H323 routing
switch back in
2003, which is still working till today (switching over 25 million minutes a
month). I've
used in conjunction with Cisco Access Servers to create various Dial-IN PPP
access routers,
and I've used it as a backend for Cisco L2TP/PPTP services, which were all
working off of
My
RE: How to capture wireless EAP packets on Windows XP?
I usually find it simplest to use tcpdump on the RADIUS server, although I've used Wireshark in the past on Windows supplicants. josh. > -Original Message- > From: > [EMAIL PROTECTED] > org > [mailto:[EMAIL PROTECTED] eradius.org] On Behalf Of Clark J. Wang > Sent: 25 July 2007 03:48 > To: freeRadius Mailing List - users > Subject: How to capture wireless EAP packets on Windows XP? > > I'm testing FreeRADIUS's PEAP-EAP-MSCHAPv2 functionality with > a wireless USB adapter (D-Link AirPlus G DWL-G122) on Windows > XP (SP2). I tried to capture the EAP packets using Wireshark > 0.99.6a but I failed. > > Anyone can help? Thanks. > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS attributes: acctoutputoctects and acctinputoctect inmikrotik
On Wed 25 Jul 2007, Santiago Balaguer García wrote: > However, I work with a Nomadix 2000 and Nomadix 2100, and I did the same > 10 MB download. So I did a test downloading the last MT firmware version: > 2.9.44 (10.4 MB): > > Nomadix [Acct-Input-Octets]: 12533328 > Nomadix [Acct-Output-Octets]: 271598 > Mikrotik[Acct-Input-Octets]: 248630 > Mikrotik[Acct-Output-Octets]: 11441495 > Are you sure that it works fine? This would appear to show that the Microtik is correct and the Nomadix is wrong... If you ware downloading from the device the the bulk of the traffic should be in the Acct-Output-Octets counter (ie. Traffic Output from the device towards you) Cheers -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS attributes: acctoutputoctects and acctinputoctect inmikrotik
However, I work with a Nomadix 2000 and Nomadix 2100, and I did the same 10 MB download. So I did a test downloading the last MT firmware version: 2.9.44 (10.4 MB):Nomadix [Acct-Input-Octets]: 12533328Nomadix [Acct-Output-Octets]: 271598Mikrotik[Acct-Input-Octets]: 248630Mikrotik[Acct-Output-Octets]: 11441495 Are you sure that it works fine? From: <[EMAIL PROTECTED]>Reply-To: FreeRadius users mailing list To: "FreeRadius users mailing list" Subject: Re: RADIUS attributes: acctoutputoctects and acctinputoctect inmikrotikDate: Tue, 24 Jul 2007 20:16:10 +0100>I have RouterOSv2.9 and input is input and output is output.>>Ivan Kalik>Kalik Informatika ISP>>>Dana 24/7/2007, "Santiago Balaguer García" <[EMAIL PROTECTED]>>pi¹e:>> >Hi,> >> > I am working with freeradius and mirkrotik routers since two years. However, I have never realized that the radius attributes acctoutputoctects and acctinputoctects are intechanged in mikrotik.> >> > Does anyone know ths mikrotik bug?> >> > SantiagoÉxitos, grandes clásicos y novedades. Un millón de canciones en MSN Music.> >> >> >>>->List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.htmlRecibe ofertas de empleo adaptadas a tu perfil. Introduce tu CV en MSN Empleo. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
