Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: Techs will also want to test switches in new installs , and they won't like waiting a day for configuration changes to take effect like users won't like the service going down every hour , although we could stagger the server restarts In reality I expect the users wouldn't even notice. It takes only a second or two to start the RADIUS server at the very most - most cases would be measured in milliseconds. With two or more redundant servers, that should be well inside the retry period of most NAS's. The risk is that the server may not come back up (eg error in the configuration that was changed) which makes automatic restarts or reloads potentially dangerous. regards, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: Coincidently started testing the 2.00 pre code in a proper environment today instead of just using radclient. All seems to stand up pretty well, no random crashes or weirdness... apart from of course the dreaded HUP which results in a segfault. That's good to hear. The HUP issue will have to be addressed before 2.0 comes out, of course. What would be really useful, is to be able to force the server to reload any of the 'file' based configuration files ... like users huntgroups files. ...and the sql based clients list, and the easiest way to do this would be via snmp. The server already supports a reload signal via SNMP, which does the same thing as HUP. Adding the ability to reload the various files may be possible. We'll see. Other options would be a cron like function, than reloads selected things periodically, or automatic change detection (which would be the neatest). And probably the most work, too. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alan DeKok wrote: Arran Cudbard-Bell wrote: Assertion failed in event.c, line 669 ... Happens after all the home servers have been marked as dead, and you have an incoming request... though could be when it's firing off a ping check event. Either way it's repeatable, and *only* happens when all home servers are dead. OK. I've gone over the code again, and fixed up a few corner cases of the state machine. That test case now works for me. Yep works for me too, reaches end of list of possible servers and starts rejecting all users assigned to that realm. :) Also little one with access-reject when home server fails to respond. Not sent through access reject filter, though that's probably because it never passes through post-auth. That will be fixed on another commit. Cool, Thanks. I'll let you know if I find any more weirdness. Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: Yep works for me too, reaches end of list of possible servers and starts rejecting all users assigned to that realm. :) Thanks. Also little one with access-reject when home server fails to respond. Not sent through access reject filter, though that's probably because it never passes through post-auth. That will be fixed on another commit. It turns out the easiest way to fix that was to remove the multiple places that called Post-Auth-Type Reject, and move it to one central location. Simpler, less code, does exactly the same thing as before, and adds the call to Post-Auth-Type Reject when the home servers fail to respond. We should probably have a Post-Proxy-Type = Fail, that gets called when a home server fails to respond to a request. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
That will be fixed on another commit. It turns out the easiest way to fix that was to remove the multiple places that called Post-Auth-Type Reject, and move it to one central location. Simpler, less code, does exactly the same thing as before, and adds the call to Post-Auth-Type Reject when the home servers fail to respond. We should probably have a Post-Proxy-Type = Fail, that gets called when a home server fails to respond to a request. That would make sense, then you can trigger a script to email admins ... etc... And well done :) Coincidently started testing the 2.00 pre code in a proper environment today instead of just using radclient. All seems to stand up pretty well, no random crashes or weirdness... apart from of course the dreaded HUP which results in a segfault. The main things that will change on our implementation will be the SQL based client list (which could change hourly). as we have a well used equipment database which the NAS list is being derived from. Techs will also want to test switches in new installs , and they won't like waiting a day for configuration changes to take effect like users won't like the service going down every hour , although we could stagger the server restarts What would be really useful, is to be able to force the server to reload any of the 'file' based configuration files ... like users huntgroups files. ...and the sql based clients list, and the easiest way to do this would be via snmp. I think this would satisfy most users requirements... if they need any more than this then they either have very strange requirements or a very poorly configured server :S. Other options would be a cron like function, than reloads selected things periodically, or automatic change detection (which would be the neatest). Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alan DeKok wrote: I've just committed massive changes to the server core. The diff is about 3k lines, and doesn't include deleted or added files. More code changes today: Multiple requests are proxied to a home server. If the home server is marked dead while the NAS is retransmitting the packets, the current code (1.x) keeps sending the retransmissions to the dead home server. In the CVS head, it now discovers that the home server is dead, and picks a live one from the appropriate server_pool. When coupled with the support for checking if a dead home server has come back to life, the server should be MUCH more robust in the event of home server failure. i.e. With the current code, many proxied requests can get rejected, even if there is a home server for the realm that is live. With the new code, all possible efforts are made to minimize the number of requests that get rejected. No other server can do better than this. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alan DeKok wrote: Alan DeKok wrote: I've just committed massive changes to the server core. The diff is about 3k lines, and doesn't include deleted or added files. More code changes today: Multiple requests are proxied to a home server. If the home server is marked dead while the NAS is retransmitting the packets, the current code (1.x) keeps sending the retransmissions to the dead home server. In the CVS head, it now discovers that the home server is dead, and picks a live one from the appropriate server_pool. When coupled with the support for checking if a dead home server has come back to life, the server should be MUCH more robust in the event of home server failure. i.e. With the current code, many proxied requests can get rejected, even if there is a home server for the realm that is live. With the new code, all possible efforts are made to minimize the number of requests that get rejected. No other server can do better than this. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html attr_filter: Matched entry jrs at line 74 modcall[pre-proxy]: module attr_filter.pre-proxy returns updated for request 13 radius_xlat: '/usr/local/freeradius/var/log//20070410/pre-proxy-detail' rlm_detail: /usr/local/freeradius/var/log//%Y%m%d/pre-proxy-detail expands to /usr/local/freeradius/var/log//20070410/pre-proxy-detail radius_xlat: 'Tue Apr 10 14:06:34 2007' modcall[pre-proxy]: module pre_proxy_log returns ok for request 13 modcall: group pre-proxy returns updated for request 13 Sending Access-Request of id 122 to 194.83.56.249 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Proxying request 13 to realm jrs, home server 194.83.56.249 port 1812 Sending Access-Request of id 122 to 194.83.56.249 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Going to the next request Cleaning up request 9 ID 125 with timestamp +60 Cleaning up request 10 ID 126 with timestamp +61 Cleaning up request 11 ID 127 with timestamp +62 Waking up in 1 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3341, id=129, length=72 Sending duplicate proxied request to home server 194.83.56.249 port 1812 - ID: 122 Sending Access-Request of id 122 to 194.83.56.249 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Waking up in 1 seconds... Cleaning up request 12 ID 128 with timestamp +63 Waking up in 15 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3341, id=129, length=72 Sending duplicate proxied request to home server 194.83.56.249 port 1812 - ID: 122 Sending Access-Request of id 122 to 194.83.56.249 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Waking up in 13 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3341, id=129, length=72 Sending duplicate proxied request to home server 194.83.56.249 port 1812 - ID: 122 Sending Access-Request of id 122 to 194.83.56.249 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Waking up in 10 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3341, id=129, length=72 FAILURE: Home server 194.83.56.249 port 1812 is dead. RETRY: Proxying request 13 to different home server 194.82.174.185 port 1812 Sending Access-Request of id 8 to 194.82.174.185 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Waking up in 7 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3341, id=129, length=72 RETRY: Proxying request 13 to different home server 194.82.174.185 port 1812 Sending Access-Request of id 179 to 194.82.174.185 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313239 Waking up in 4 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3341, id=129, length=72 radiusd(24731) malloc: *** Deallocation of a pointer not malloced: 0x5d4e80; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug RETRY: Proxying request 13 to different home server 194.82.174.185 port 1812 Sending Access-Request of id 89 to 194.82.174.185 port 1812
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: Alan DeKok wrote: Alan DeKok wrote: I've just committed massive changes to the server core. The diff is about 3k lines, and doesn't include deleted or added files. More code changes today: Multiple requests are proxied to a home server. If the home server is marked dead while the NAS is retransmitting the packets, the current code (1.x) keeps sending the retransmissions to the dead home server. In the CVS head, it now discovers that the home server is dead, and picks a live one from the appropriate server_pool. When coupled with the support for checking if a dead home server has come back to life, the server should be MUCH more robust in the event of home server failure. i.e. With the current code, many proxied requests can get rejected, even if there is a home server for the realm that is live. With the new code, all possible efforts are made to minimize the number of requests that get rejected. No other server can do better than this. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html It seems to be occuring when the freeradius switches from the dead home_server to another in the pool. Repeatable, happens on every transition to new proxy server. Looks like a pretty generic memory allocation error, but I can provide platform / library information if it'll help. When it works it'll be awesome :D --- Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: ... FAILURE: Home server 194.83.56.249 port 1812 is dead. RETRY: Proxying request 13 to different home server 194.82.174.185 port 1812 ... Didn't do that before :S Yup. $ cvs update $ make :) Also, if you have SNMP enabled, it now prints out that it's listening on the SNMP socket... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alan DeKok wrote: Got another one for you :P rlm_detail: /usr/local/freeradius/var/log//%Y%m%d/pre-proxy-detail expands to /usr/local/freeradius/var/log//20070410/pre-proxy-detail radius_xlat: 'Tue Apr 10 18:34:28 2007' modcall[pre-proxy]: module pre_proxy_log returns ok for request 31 modcall: group pre-proxy returns updated for request 31 Sending Access-Request of id 166 to 194.83.56.233 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x3135 Proxying request 31 to realm jrs, home server 194.83.56.233 port 1812 Sending Access-Request of id 166 to 194.83.56.233 port 1812 Service-Type := Authenticate-Only User-Name = [EMAIL PROTECTED] NAS-IP-Address = 139.184.8.1 Proxy-State = 0x3135 Going to the next request Cleaning up request 27 ID 11 with timestamp +641 Cleaning up request 28 ID 12 with timestamp +642 Sending Access-Request of id 188 to 194.83.56.249 port 1812 User-Name := [EMAIL PROTECTED] User-Password := just_testing Service-Type := Authenticate-Only Message-Authenticator := 0x NAS-Identifier := Ping! Are you alive? Sending Access-Request of id 81 to 194.82.174.185 port 1812 User-Name := [EMAIL PROTECTED] User-Password := just_testing Service-Type := Authenticate-Only Message-Authenticator := 0x NAS-Identifier := Ping! Are you alive? Cleaning up request 29 ID 13 with timestamp +643 Waking up in 1 seconds... rad_recv: Access-Request packet from host 81.6.252.244 port 3363, id=15, length=72 FAILURE: Home server 194.83.56.233 port 1812 is dead. Failed to find live home server for request 31 There was no response configured: rejecting request 31 Sending Access-Reject of id 15 to 81.6.252.244 port 3363 Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Tunnel-Private-Group-Id = 134 Service-Type = Framed-User Finished request 31 state 5 Waking up in 1 seconds... Cleaning up request 30 ID 14 with timestamp +644 Waking up in 2 seconds... No response to ping 32 from home server 194.83.56.249 port 1812 Cleaning up request 32 with timestamp +647 No response to ping 33 from home server 194.82.174.185 port 1812 Cleaning up request 33 with timestamp +648 Waking up in 12 seconds... Assertion failed in event.c, line 669 Abort *process death* Happens after all the home servers have been marked as dead, and you have an incoming request... though could be when it's firing off a ping check event. Either way it's repeatable, and *only* happens when all home servers are dead. Also little one with access-reject when home server fails to respond. Not sent through access reject filter, though that's probably because it never passes through post-auth. Sending Access-Request of id 14 to 139.184.14.181 port 1812 User-Name = [EMAIL PROTECTED] User-Password = poptart1 Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 rad_recv: Access-Reject packet from host 139.184.14.181:1812, id=14, length=67 Reply-Message = Please use [EMAIL PROTECTED] as your user ID Sending Access-Request of id 15 to 139.184.14.181 port 1812 User-Name = [EMAIL PROTECTED] User-Password = poptart1 Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 Re-sending Access-Request of id 15 to 139.184.14.181 port 1812 User-Name = [EMAIL PROTECTED] User-Password = poptart1 Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 rad_recv: Access-Reject packet from host 139.184.14.181:1812, id=15, length=43 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = 134 Service-Type = Framed-User and finally, how do you define a binding for the snmp module it's on, but I never explicitly bound it to anywhere :| unlike auth/acct that are bound with listen sections. Seems like there may be a need for a small extension to listen sections to allow type snmp . Sorry for breaking it again :( --- Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
On Tuesday 10 April 2007 13:51:29 Arran Cudbard-Bell wrote: and finally, how do you define a binding for the snmp module it's on, but I never explicitly bound it to anywhere :| unlike auth/acct that are bound with listen sections. Seems like there may be a need for a small extension to listen sections to allow type snmp . Arran, http://wiki.freeradius.org/SNMP_HOWTO That page should give some base info on setting up SNMP support. Kevin Bonner pgp4G1jfBRBqQ.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Kevin Bonner wrote: On Tuesday 10 April 2007 13:51:29 Arran Cudbard-Bell wrote: and finally, how do you define a binding for the snmp module it's on, but I never explicitly bound it to anywhere :| unlike auth/acct that are bound with listen sections. Seems like there may be a need for a small extension to listen sections to allow type snmp . Arran, http://wiki.freeradius.org/SNMP_HOWTO That page should give some base info on setting up SNMP support. Kevin Bonner - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Yuhu, but doesn't explain how to bind the snmp port to a specific ip address on a multi homed server ;-) --- Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: Kevin Bonner wrote: On Tuesday 10 April 2007 13:51:29 Arran Cudbard-Bell wrote: and finally, how do you define a binding for the snmp module it's on, but I never explicitly bound it to anywhere :| unlike auth/acct that are bound with listen sections. Seems like there may be a need for a small extension to listen sections to allow type snmp . Arran, http://wiki.freeradius.org/SNMP_HOWTO That page should give some base info on setting up SNMP support. Kevin Bonner - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Yuhu, but doesn't explain how to bind the snmp port to a specific ip address on a multi homed server ;-) --- Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Oh wait, snmp module connects to another snmp server ... oops. My bad, never played with it before :) Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: ... Assertion failed in event.c, line 669 Hmm... OK. Happens after all the home servers have been marked as dead, and you have an incoming request... though could be when it's firing off a ping check event. Either way it's repeatable, and *only* happens when all home servers are dead. It's a good test case. Also little one with access-reject when home server fails to respond. Not sent through access reject filter, though that's probably because it never passes through post-auth. Yes. It should really run post-proxy-type = FAIL, or something like that, followed by the access reject filter. Right now, the goal is to add the new features, make them stable, and then touch it up around the edges. and finally, how do you define a binding for the snmp module it's on, but I never explicitly bound it to anywhere :| snmp.conf FreeRADIUS connects to the SNMP daemon, and there's little else to configure. unlike auth/acct that are bound with listen sections. Seems like there may be a need for a small extension to listen sections to allow type snmp . No. FreeRADIUS isn't an SNMP server. It *registers* itself with an SNMP server, and the SNMP server calls FreeRADIUS whenever something needs to get done. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: Assertion failed in event.c, line 669 ... Happens after all the home servers have been marked as dead, and you have an incoming request... though could be when it's firing off a ping check event. Either way it's repeatable, and *only* happens when all home servers are dead. OK. I've gone over the code again, and fixed up a few corner cases of the state machine. That test case now works for me. Also little one with access-reject when home server fails to respond. Not sent through access reject filter, though that's probably because it never passes through post-auth. That will be fixed on another commit. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: At least in 1.1.5 it doesn't fall through properly if a user belongs to multiple groups and the check items in the first group partially match.. In which version did it stop working? Least that my experience. Anyway, nice work on pre 2.0 , looking forward to it in anticipation. There are a few more things that have to go in, and then we can do a 2.0. I'll leave off the magic features for 2.1, as it's way past time 2.0 should be released. Is freeradius development quite closed, or is it open to everyone ? One of our mantras is As always, patches are welcome. However, we get the occasional email from people saying I have a patch... give me CVS commit access. The answer is always No.. Patches get audited for security, code style, etc. before they get applied. Some patches get completely re-written. People get CVS commit access after all of their patches go in with minimal changes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
At least in 1.1.5 it doesn't fall through properly if a user belongs to
multiple groups and the check items in the first group partially match..
In which version did it stop working?
I will investigate, as far as I could tell it was still broken in the CVS head..
Oh btw, are dotted ip addresses supported in CIDR format as check items
? I've been using regular expressions, but CIDR would be easier.
Let me check i've got the theory of groups correct first.
Ok, there used to be a directive in sql.conf that forced rlm_sql to
check groups, this is now depricated and no longer used ?
So rlm_sql will check groups for the user in every case.
The sql group check query, selects all the rows in the 'radgroupcheck'
table, that has a group id that matches the id of any of the groups the
user is marked a member of in the 'usergroup' table.
It then runs much the same query for the 'radgroupreply' table.
It works down the list of groups in order of priority which it's gleaned
from the usergroup table.
Or at least it should, but it doesn't in 1.1.5. The result from the
default queries is actually ordered by the auto incremented ID in the
groupcheck and group reply tables,
it should be ordered by the priority in the user groups table Or
rlm_sql should at least pull the priority field out of the database and
process the groups in that order...
When you think about it, this screws quite a few things up If you
are relying on the group priority with groups of lower priorities having
the fall-through directive to false
So to illustrate
SELECT
radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op
FROM radgroupcheck,usergroup WHERE usergroup.Username = 'ac221' AND
usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id
1 nas_admins Service-Type7
==
2 nas_admins NAS-IP-Address ^(139[.]184[.]8[.])([0-9]{0,3})$
=~
5 roaming_users Service-Type5 ==
In the users group table however, roaming_users has a higher priority
than nas admins (priority of 2) , so it should be listed first but it's
ovbiously not.
SELECT
radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op
FROM radgroupcheck,usergroup WHERE usergroup.Username = 'ac221' AND
usergroup.GroupName = radgroupcheck.GroupName ORDER BY
usergroup.priority DESC, radgroupcheck.GroupName
5 roaming_users Service-Type5 ==
9 nas_admins Service-Type7 ==
2 nas_admins NAS-IP-Address ^(139[.]184[.]8[.])([0-9]{0,3})$
=~
So now, as long as the groups are processed in order then the priority
field will be honoured. If not the priority should be included in the
select query and it should be honoured by rlm_sql.
Anyway first issue over :)
Second issue, is when user ac221 belongs to both groups, if any of the
check items match in nas_admins then it won't check roaming_users check
items. Which means if a user is setup as a nas admin, they don't get the
any vlan information sent when they connect as a framed user
As far as I can tell this has been broken since 1.1.5 as is still broken
in the cvs head. I can try and dig out a copy of 1.1.4 and check if you
want ?
SQL rows as follows..
user groups
ac221 roaming_users 2
ac221 nas_admins 1
check items
9 nas_admins Service-Type== 7
2 nas_admins NAS-IP-Address =~ ^(139[.]184[.]8[.])([0-9]{0,3})$
3 nas_operators Service-Type== 7
4 nas_operators NAS-IP-Address =~ ^(139[.]184[.]8[.])([0-9]{0,3})$
5 roaming_users Service-Type== 5
reply items
1 nas_admins Service-Type= 6
2 nas_operators Service-Type= 7
3 roaming_users Tunnel-Type = 13
4 roaming_users Tunnel-Medium-Type = 6
5 roaming_users Tunnel-Private-Group-ID = 134
Login to NAS works fine.
Login to AP results in user not found, and attributes not being sent :(.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Is freeradius development quite closed, or is it open to everyone ? One of our mantras is As always, patches are welcome. However, we get the occasional email from people saying I have a patch... give me CVS commit access. The answer is always No.. Patches get audited for security, code style, etc. before they get applied. Some patches get completely re-written. People get CVS commit access after all of their patches go in with minimal changes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Yes, completely understandable :) So all potential patches should be created against the CVS head, and submitted to the developers mailing list ? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: So all potential patches should be created against the CVS head, and submitted to the developers mailing list ? That's probably the quickest way. You can also open an issue on the bug tracker, but that isn't always necessary for simple patches. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: So all potential patches should be created against the CVS head, and submitted to the developers mailing list ? That's probably the quickest way. You can also open an issue on the bug tracker, but that isn't always necessary for simple patches. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alan, thinking about upcoming upgrade from 1.1.5 to 2.0 i tried 2.0 with
my configuration from 1.1.5.
There seem to be some difference which i hope you can explain.
proxy.conf configuration is
realm NULL {
type= radius
authhost= LOCAL
accthost= LOCAL
}
and we have a user who has simple radcheck entry in sql:
mobile Auth-Type:=accept
in 1.1.5 radiusd performs authorize and authorize group checks in sql:
rlm_sql (sqlauth): sql_set_user escaped user -- 'mobile'
radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE
Username = 'mobile' ORDER BY id'
rlm_sql (sqlauth): Reserving sql socket id: 4
radius_xlat: 'SELECT
radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op
FROM radgroupcheck,usergroup WHERE (usergroup.Username = 'mobile' or
usergroup.CLID = '25009740996') AND usergroup.GroupName =
radgroupcheck.GroupName ORDER BY usergroup.PRIORITY,radgroupcheck.id'
radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE
Username = 'mobile' ORDER BY id'
radius_xlat: 'SELECT
radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op
FROM radgroupreply,usergroup WHERE (usergroup.Username = 'mobile' OR
usergroup.CLID = '25009740996') AND usergroup.GroupName =
radgroupreply.GroupName ORDER BY radgroupreply.id'
rlm_sql (sqlauth): Released sql socket id: 4
modcall[authorize]: module sqlauth returns ok for request 0
modcall: leaving group authorize (returns ok) for request 0
rad_check_password: Found Auth-Type Accept
rad_check_password: Auth-Type = Accept, accepting the user
Login OK: [mobile] (from client localhost port 0 cli 25009740996)
but in 2.0 we lack the group checks:
rlm_sql (sqlauth): sql_set_user escaped user -- 'mobile'
rlm_sql (sqlauth): Reserving sql socket id: 4
radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE
Username = 'mobile' ORDER BY id'
rlm_sql (sqlauth): User found in radcheck table
radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE
Username = 'mobile' ORDER BY id'
rlm_sql (sqlauth): Released sql socket id: 4
modcall[authorize]: module sqlauth returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type Accept
rad_check_password: Auth-Type = Accept, accepting the user
Login OK: [mobile] (from client localhost port 0 cli 25009700040996)
what could be the possible reason(s) of that?
Alan DeKok wrote:
I've just committed massive changes to the server core. The diff is
about 3k lines, and doesn't include deleted or added files.
The good news is that it looks to be nearly 100% backwards compatible
with the configurations currently allowed by the CVS head. That is,
I've written it to be backwards compatible, and validated it via tests,
but I won't claim it's perfect until people test it.
...
--
Sincerely Yours,
Alexander
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Alexander Serkin wrote:
Alan, thinking about upcoming upgrade from 1.1.5 to 2.0 i tried 2.0 with
my configuration from 1.1.5.
There seem to be some difference which i hope you can explain.
proxy.conf configuration is
realm NULL {
type= radius
authhost= LOCAL
accthost= LOCAL
}
That should work.
and we have a user who has simple radcheck entry in sql:
mobileAuth-Type:=accept
in 1.1.5 radiusd performs authorize and authorize group checks in sql:
...
but in 2.0 we lack the group checks:
...
what could be the possible reason(s) of that?
No idea. I haven't been using the SQL module, so I'm not sure what it
could be, sorry.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
In 2.0 we lack the group checks: I thought group checks were slightly broken since 1.1.3 anyway if not can someone please close the bug report :) At least in 1.1.5 it doesn't fall through properly if a user belongs to multiple groups and the check items in the first group partially match.. Least that my experience. Anyway, nice work on pre 2.0 , looking forward to it in anticipation. Is freeradius development quite closed, or is it open to everyone ? --- Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0 is a lot closer to reality...
Arran Cudbard-Bell wrote: In 2.0 we lack the group checks: I thought group checks were slightly broken since 1.1.3 anyway if not can someone please close the bug report :) At least in 1.1.5 it doesn't fall through properly if a user belongs to multiple groups and the check items in the first group partially match.. Hm. I did not notice that. Walked through 1.1.3,4,5 transparently without problems for users living in 2 or more groups. Though i slightly modified group authorization queries and usergroup table (added CLID field). -- Sincerely Yours, Alexander - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Version 2.0 is a lot closer to reality...
I've just committed massive changes to the server core. The diff is about 3k lines, and doesn't include deleted or added files. The good news is that it looks to be nearly 100% backwards compatible with the configurations currently allowed by the CVS head. That is, I've written it to be backwards compatible, and validated it via tests, but I won't claim it's perfect until people test it. The new features include: - full IPv6 support for proxying (finally) - realms have been split into server pools and home servers (see proxy.conf for details) - deletion of old horrid code that did Walking the entire request list - move to event-based core, so that things happen when necessary, rather than accidentally as a side of effect of trial error. - new Status-Server ping capability, so that home servers transitioning from dead - live are automatically discovered and used. See proxy.conf for details of most of the new features. This patch does *not* include a number of other features which are currently sitting in my queue. For those interested in code details, see src/main/event.c, and src/main/realms.c. The code is much simpler than before, and substantially easier to understand. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
