FreeRADIUS 3.x package coming - BETA for TESTING
-
How did those look in FreeRADIUS 2.x?
What specific settings are in place for those users in the GUI? -
I have vlan assigned by radius.
In 2.x it was like this:
"tosh" Cleartext-Password := "asdadadada", Simultaneous-Use := "1"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = "3"I have it working by editing /usr/local/etc/raddb/users by hand and correcting those errors above. Removed the ; and
Session-Timeout := 3600,Restarted the service in GUI without saving and voilรก. It worked.
EDIT: I use unifi APs and controller and have it configured so users get vlan assigned by the radius.
-
OK I think I got those formatting issues fixed, whenever 0.5.1 shows up give it a shot.
-
Thanks jimp. It's working now.
-
Great!
I think at this point it's passed all of the tests that I had written down. I'd still like to see some more feedback though before I declare it ready for general use. Definitely progressed past Alpha and into Beta territory though at least.
-
That's good news. I think it's ready at least to beta. I even solved a problem I had with my mpower strip not authenticating.
-
Jun 16 11:13:41 radiusd 31670 Ready to process requests Jun 16 11:13:41 radiusd 31670 Loaded virtual server default Jun 16 11:13:41 radiusd 31670 Loaded virtual server inner-tunnel-peap Jun 16 11:13:41 radiusd 31670 Loaded virtual server inner-tunnel-ttls Jun 16 11:13:41 radiusd 31670 Ignoring "ldap" (see raddb/mods-available/README.rst) Jun 16 11:13:41 radiusd 31670 Ignoring "sql" (see raddb/mods-available/README.rst) Jun 16 11:13:41 radiusd 31670 Loaded virtual server <default>Jun 16 11:13:41 radiusd 31670 [/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay-USec" found in filter list for realm "DEFAULT". Jun 16 11:13:41 radiusd 31670 [/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay" found in filter list for realm "DEFAULT". Jun 16 11:13:40 radiusd 30527 Debugger not attached Jun 16 11:13:25 php-fpm 49443 [pfBlockerNG] Starting cron process. Jun 16 11:13:25 php-fpm 49443 /rc.start_packages: Restarting/Starting all packages. Jun 16 11:13:24 check_reload_status Starting packages Jun 16 11:13:24 check_reload_status Reloading filter Jun 16 11:13:22 pkg pfSense-pkg-freeradius3 upgraded: 0.5.1 -> 0.6_4</default>
Where's that error coming from?
EDIT: Might not be a real error. Just a warning. What do you think, jimp?
-
Seems to be cosmetic
https://github.com/FreeRADIUS/freeradius-server/pull/1216#issuecomment-138924345
http://lists.freeradius.org/pipermail/freeradius-users/2015-October/080219.html
Short version: that warning is harmless. If you want to get rid of it,
just remove the two lines from attr_filter/access_reject, there will be
no behaviour changes.Longer version: The check you're seeing tries to warn us that we allow
an attribute in the reply-list that we cannot send in an Access-Reject.
The functionality has been added in PR #1216 to allow packet specific
overrides of the reject_delay, so in this case we're not adding the
attribute to send it to the client, but we're adding it to change
something inside FreeRADIUS.I guess there are two simple options to remove this warning:
- Set those attributes in another list than reply
- Remove the warning from rlm_attr_filter
-
:D You beat me to it. I was just adding that to my previous post. Thanks for checking.
-
Yeah that seems completely cosmetic, it doesn't actually say "error"/"warning"/"failure" like some other messages do.
I'm not terribly worried about it, I'd just let it go. -
Would seem simple enough to make it go away if you want.. I don't normally like stuff like that in a boot/start of a application ;) Prob fix it up at some point - the edit seems easy enough..
"just remove the two lines from attr_filter/access_reject, there will be no behaviour changes."
-
It is not as simple as that. Easy to say, but not easy to do from a package standpoint. We don't put those lines in and the file is part of the stock package. So we couldn't just edit the lines out. We'd either have to write out our own local copy of the file and overwrite that one each time, or concoct some scheme to remove the lines with sed, etc.
Since it's harmless, for now I'll just let it be.
-
oh not talking about in the package - I am talking for the user to edit out those if they don't like the the info.
I agree doing such a thing programmatically in the package script bit more difficult ;)
-
FYI- The package is now up for 2.3.4 users to test out, too.