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:

mobile Auth-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

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

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-Type 7 == 2 nas_admins NAS-IP-Address ^(139[.]184[.]8[.])([0-9]{0,3})$ =~ 5 roaming_users Service-Type 5 == 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-Type 5 == 9 nas_admins Service-Type 7 == 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 :(.

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

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

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 = "ac221@brighton.ac.uk" 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 = "ac221@brighton.ac.uk" 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 := "test_user@sussex" User-Password := "just_testing" Service-Type := Authenticate-Only Message-Authenticator := 0x00000000000000000000000000000000 NAS-Identifier := "Ping! Are you alive?" Sending Access-Request of id 81 to 194.82.174.185 port 1812 User-Name := "test_user@sussex" User-Password := "just_testing" Service-Type := Authenticate-Only Message-Authenticator := 0x00000000000000000000000000000000 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 = "ac221@spazland.sussex.ac.uk" 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 ac221@sussex.ac.uk as your user ID" Sending Access-Request of id 15 to 139.184.14.181 port 1812 User-Name = "ac221@brighton.ac.uk" 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 = "ac221@brighton.ac.uk" 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

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

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

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

...

...

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

Murray Hooper wrote:

Are there any open source programs that parse the accounting logs produced by freeradius? I can find a couple in Google, but they appear to have been left behind in 1999.

Accounting detail file formats haven't changed in years, so they probably work fine. I recall radiusContext was quite good when I last used it, and it's written in python so should be very easy to extend. They reason you probably didn't find many is that often people push the accounting into an SQL server, either directly using rlm_sql, relayed using rlm_sql_log or via radrelay and a 2nd server, which obviously makes most of these packages redundant for parsing purposes.

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

Excuse the greenness of question. Is there a 'how-to' on authreply_table? I am just starting with freeradius + mysql and want to get freeradius to do a db dip and respond with required plus a couple extra fields of data to the NAS. Appreciated murray