Re: Last call for 2.1.10
Alan Buxey wrote: > Hi, > >> The only bug here is that the server should complain if you have two >> instances of the same module defined. That would prevent the server >> from starting in this case, and highlight the fact that the >> configuration is wrong. > > that would be the obvious and ideal way to deal with things...but I wouldnt > advocate such a change occuring right now in 2.1.10 - we have no idea > of how many installations have multiple copies of same module and they've > got away with it Pretty much, yes. Maybe for 2.1.11 it could be a WARNING. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Alexander Clouter wrote: > Alan DeKok wrote: >> If there are any issues, let me know now. Otherwise we'll release >> 2.1.10 on Monday. >> > Is it worth tweaking the eap.conf comment so that it is explicitly > mentioned that for session resumption to work sensibly for TTLS/PEAP > that 'use_tunneled_reply' should be set to 'yes'? Sure. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Alan DeKok wrote: > > If there are any issues, let me know now. Otherwise we'll release > 2.1.10 on Monday. > Is it worth tweaking the eap.conf comment so that it is explicitly mentioned that for session resumption to work sensibly for TTLS/PEAP that 'use_tunneled_reply' should be set to 'yes'? Cheers -- Alexander Clouter .sigmonster says: No yak too dirty; no dumpster too hollow. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Hi, > The only bug here is that the server should complain if you have two > instances of the same module defined. That would prevent the server > from starting in this case, and highlight the fact that the > configuration is wrong. that would be the obvious and ideal way to deal with things...but I wouldnt advocate such a change occuring right now in 2.1.10 - we have no idea of how many installations have multiple copies of same module and they've got away with it alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Stefan Winter wrote: > One thing has changed from recently: on my openSUSE 11.2 i586 > previously, I had to compile ---with-system-libtool, and *not using > that* would break the build. > Now, it's vice versa: --with-system-libtool breaks, and without it, > stuff works. Yes... I changed it so that the defaults were to use local libtool && libltdl. The system versions are "updated", and use incompatible APIs. So if you use system/local or local/system libtool/libltdl, the build breaks in strange and mysterious ways. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Hi, compiled and runs on a test server (but no real traffic load). One thing has changed from recently: on my openSUSE 11.2 i586 previously, I had to compile ---with-system-libtool, and *not using that* would break the build. Now, it's vice versa: --with-system-libtool breaks, and without it, stuff works. Strange; but never mind. Greetings, Stefan Winter Am 22.09.2010 15:15, schrieb Alan DeKok: I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. The changelog is *extensive*. There are a large number of minor bugs fixed, and a lot of minor new features added. But the result is that the server has taken a significant step ahead in usability and functionality. Thanks to everyone for testing intermediate releases. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
John Dennis wrote: > I just noticed the redhat/freeradius.spec file wasn't fully updated in > 2.1.0. It was missing the dynamic_clients and opendirectory modules in > the %files section. Also the release tag was left at 2 instead of being > reset to 1. Attached is a patch, in addition to the above it adds the > changelog information. Added, thanks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
I just noticed the redhat/freeradius.spec file wasn't fully updated in
2.1.0. It was missing the dynamic_clients and opendirectory modules in
the %files section. Also the release tag was left at 2 instead of being
reset to 1. Attached is a patch, in addition to the above it adds the
changelog information.
--
John Dennis
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
--- freeradius-server-2.1.10/redhat/freeradius.spec 2010-09-22 05:50:14.0 -0400
+++ freeradius.spec 2010-09-22 13:11:44.0 -0400
@@ -1,7 +1,7 @@
Summary: High-performance and highly configurable free RADIUS server
Name: freeradius
Version: 2.1.10
-Release: 2%{?dist}
+Release: 1%{?dist}
License: GPLv2+ and LGPLv2+
Group: System Environment/Daemons
URL: http://www.freeradius.org/
@@ -325,6 +325,7 @@
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/detail.example.com
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/detail.log
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/digest
+%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/dynamic_clients
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/echo
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/etc_group
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/exec
@@ -339,6 +340,7 @@
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/mac2vlan
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/mschap
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/ntlm_auth
+%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/opendirectory
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/otp
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/pam
%attr(640,root,radiusd) %config(noreplace) /etc/raddb/modules/pap
@@ -557,6 +559,226 @@
%{_libdir}/freeradius/rlm_sql_unixodbc-%{version}.so
%changelog
+* Wed Sep 22 2010 John Dennis - 2.1.10-1
+- upgrade to latest upstream release
+ Feature improvements
+ * Install the "radcrypt" program.
+ * Enable radclient to send requests containing MS-CHAPv1
+Send packets with: MS-CHAP-Password = "password". It will
+be automatically converted to the correct MS-CHAP attributes.
+ * Added "-t" command-line option to radtest. You can use "-t pap",
+ "-t chap", "-t mschap", or "-t eap-md5". The default is "-t pap"
+ * Make the "inner-tunnel" virtual server listen on 127.0.0.1:18120
+This change and the previous one makes PEAP testing much easier.
+ * Added more documentation and examples for the "passwd" module.
+ * Added dictionaries for RFC 5607 and RFC 5904.
+ * Added note in proxy.conf that we recommend setting
+"require_message_authenticator = yes" for all home servers.
+ * Added example of second "files" configuration, with documentation.
+This shows how and where to use two instances of a module.
+ * Updated radsniff to have it write pcap files, too. See '-w'.
+ * Print out large WARNING message if we send an Access-Challenge
+for EAP, and receive no follow-up messages from the client.
+ * Added Cached-Session-Policy for EAP session resumption. See
+raddb/eap.conf.
+ * Added support for TLS-Cert-* attributes. For details, see
+raddb/sites-available/default, "post-auth" section.
+ * Added sample raddb/modules/{opendirectory,dynamic_clients}
+ * Updated Cisco and Huawei, HP, Redback, and ERX dictionaries.
+ * Added RFCs 5607, 5904, and 5997.
+ * For EAP-TLS, client certificates can now be validated using an
+external command. See eap.conf, "validate" subsection of "tls".
+ * Made rlm_pap aware of {nthash} prefix, for compatibility with
+legacy RADIUS systems.
+ * Add Module-Failure-Message for mschap module (ntlm_auth)
+ * made rlm_sql_sqlite database configurable. Use "filename"
+in sql{} section.
+ * Added %{tolower: ...string ... }, which returns the lowercase
+version of the string.
+
+ Bug fixes
+ * Fix endless loop when there are multiple sub-options for
+DHCP option 82.
+ * More debug output when sending / receiving DHCP packets.
+ * EAP-MSCHAPv2 should return the MPPE keys when used outside
+of a TLS tunnel. This is needed for IKE.
+ * Added SSL "no ticket" option to prevent SSL from creating sessions
+without IDs. We need the IDs, so this option should be set.
+ * Fix proxying of packets from inside a TTLS/PEAP tunnel.
+Closes bug #25.
+ * Allow IPv6 address attributes to be created from domain names
+Closes bug #82.
+ * Set the string length to the correct value when parsing double
+quotes. Closes bug #88.
+ * No longer look users up in /etc/passwd in the default configuration.
+This can be reverted by enabling "unix" in the "authorize" section.
+ * More #ifdef's to enable building on systems without certain
+features.
+ * Fixed SQL-Group comparison to register only if the group
+query is defined.
+ * Fixed SQL-Group comparison to reg
Re: Last call for 2.1.10
On Thu, 2010-09-23 at 12:05 +0200, Alan DeKok wrote: > John Horne wrote: > > So, I guess the question is why is freeradius reloading the post-proxy > > filter a second time after the HUP? > > The question is why do you have two configurations for the same module? > > The only bug here is that the server should complain if you have two > instances of the same module defined. That would prevent the server > from starting in this case, and highlight the fact that the > configuration is wrong. > Ah, okay our mistake. Sorry about that. As far as I remember we created the module with the same name and it seemed to work. Obviously 'seemed to work' is not the same as 'works in all cases', and not necessarily the right way to do things. We will rename our local module. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
John Horne wrote:
> We also have the file /etc/raddb/modules-local/attr_filter which
> contains:
Have you *deleted* the default configuration for the
attr_filter.post-proxy module?
If not, you have *two* copies of the module configuration. That's why
it's having issues. It picks on the first time, and a different one the
second time.
> attr_filter attr_filter.post-proxy {
> attrsfile = ${confdir}/attrs.post-proxy
> }
>
> So when freeradius starts up it reads this file, and uses the defined
> module in preference to the one in the
> file /etc/raddb/modules/attr_filter.
OK... so why do you still have the default one in the configuration?
Delete it, or rename your module, and update the server configuration to
use the new name.
> So, I guess the question is why is freeradius reloading the post-proxy
> filter a second time after the HUP?
The question is why do you have two configurations for the same module?
The only bug here is that the server should complain if you have two
instances of the same module defined. That would prevent the server
from starting in this case, and highlight the fact that the
configuration is wrong.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On 2010/09/22 03:15 PM, Alan DeKok wrote: I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. Would be nice to remove "+git" from debian/changelog -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Wed, 2010-09-22 at 18:02 +0100, John Horne wrote:
>
> The failed login has no MS-CHAP2-Success attribute being sent back.
>
Okay. The problem is to do with attribute filtering, but that in turn
seems to be caused by freeradius doing something unexpected when it
receives the HUP.
We define the file /etc/raddb/attrs.post-proxy which contains the
following:
plymouth.ac.uk
MS-CHAP2-Success =* ANY,
Fall-Through = Yes
NULL
MS-CHAP2-Success =* ANY,
Fall-Through = Yes
DEFAULT
Service-Type == Framed-User,
Service-Type == Login-User,
Login-Service == Telnet,
... (other attributes/values)
We also have the file /etc/raddb/modules-local/attr_filter which
contains:
attr_filter attr_filter.post-proxy {
attrsfile = ${confdir}/attrs.post-proxy
}
So when freeradius starts up it reads this file, and uses the defined
module in preference to the one in the
file /etc/raddb/modules/attr_filter. Running 'radiusd -X' shows:
===
Starting - reading configuration files ...
...
including configuration file /etc/raddb/modules-local/attr_filter
...
including configuration file /etc/raddb/modules/attr_filter
...
Module: Checking post-proxy {...} for more modules to load
Module: Instantiating module "attr_filter.post-proxy" from
file /etc/raddb/modules-local/attr_filter
attr_filter attr_filter.post-proxy {
attrsfile = "/etc/raddb/attrs.post-proxy"
key = "%{Realm}"
}
===
As can be seen the correct module file is used. Now lets do a HUP:
===
... new connection request on command socket.
Listening on command file /var/run/radiusd/radiusd.sock
Ready to process requests.
radmin> hup
Ready to process requests.
Received HUP signal.
HUP - Re-reading configuration files
...
including configuration file /etc/raddb/modules-local/attr_filter
...
including configuration file /etc/raddb/modules/attr_filter
...
Module: Trying to reload module "attr_filter.post-proxy"
attr_filter attr_filter.post-proxy {
attrsfile = "/etc/raddb/attrs.post-proxy"
key = "%{Realm}"
}
Module: Reloaded module "attr_filter.post-proxy"
...
Module: Trying to reload module "attr_filter.post-proxy"
attr_filter attr_filter.post-proxy {
attrsfile = "/etc/raddb/attrs"
key = "%{Realm}"
}
Module: Reloaded module "attr_filter.post-proxy"
===
As can be seen, after the HUP freeradius loads the original file, but
then reloads the default one (/etc/raddb/modules/attr_filter which uses
"/etc/raddb/attrs"). This default filter file has no MS-CHAP2-Success
entry, so that attribute would be filtered out.
Looking at the processing of the access accept packet shows this too:
===
rad_recv: Access-Accept packet from host 141.163.195.250 port 1812,
id=137, length=194
Framed-IP-Address = 141.163.192.64
MS-MPPE-Encryption-Types = 0x0004
MS-MPPE-Encryption-Policy = 0x0002
MS-CHAP2-Success =
0x8c533d32373939374535323141364234394141453336314337343341313436383936323043393032433045
Reply-Message = "Yes"
MS-MPPE-Recv-Key = 0xf6ee626fa0a9ceea0c565916916e4a5a
MS-MPPE-Send-Key = 0x12c24a8d04f33b97b786c120f155aa4f
Proxy-State = 0x3338
# Executing section post-proxy from
file /etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
[files] users: Matched entry jhorne at line 213
[files] expand: %{User-Name} -> jhorne
[files] expand: %{User-Name} -> jhorne
[files] expand: %{User-Name} -> jhorne
[files] expand: %{Calling-Station-Id} -> 141.163.60.243
[files] users: Matched entry DEFAULT at line 269
++[files.authorize] returns ok
[attr_filter.post-proxy]expand: %{Realm} -> NULL
attr_filter: Matched entry DEFAULT at line 103
++[attr_filter.post-proxy] returns updated
===
The 'Matched entry DEFAULT at line 103' is from the
file /etc/raddb/attrs, and so the MS-CHAP2-Success attribute is removed
and the client see a failure/reject rather than a success.
The 'radiusd -X' output when a HUP hasn't been given shows:
===
[attr_filter.post-proxy]expand: %{Realm} -> NULL
attr_filter: Matched entry NULL at line 5
attr_filter: Matched entry DEFAULT at line 9
++[attr_filter.post-proxy] returns updated
===
And the lines 5 and 9 correspond to our defined file which allow for the
MS-CHAP2-Success attribute.
So, I guess the question is why
Re: Last call for 2.1.10
On 09/22/2010 09:15 AM, Alan DeKok wrote: I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. I verified 2.1.10 builds and produces an RPM. My apologies but I don't have time at the moment to test and exercise the resulting RPM's. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Alan DeKok writes: > I've put some preliminary tar files on: > > http://git.freeradius.org/pre/ > > If there are any issues, let me know now. Otherwise we'll release > 2.1.10 on Monday. A little late into the game, but I just noticed this: bj...@nemi:~$ radclient -v radclient: $Id$ built on Jun 18 2010 at 03:16:11 I guess the RCS keyword is leftover from when CVS was used. I propose replacing it with RADIUSD_VERSION. Will followup with a minimalistic patch shortly. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Wed, 2010-09-22 at 18:53 +0200, Alan DeKok wrote:
> John Horne wrote:
> > The problem seems to be that although the proxy server returns a 'Yes'
> > reply (meaning the user is authenticated)
>
> What does that mean? There is no standard attribute to transport a "Yes".
>
Sorry, the 'Yes' is just the reply-message from the proxy server.
> > Although this looks like a pppd problem, it only occurs after we have
> > issued 'radmin -e hup'. If we don't use the control-socket, or just use
> > it without issuing a 'hup', then pppd works fine.
>
> Use tcpdump to see what the Access-Accepts look like before && after
> the HUP.
>
I ran radiusd -X instead and saw:
For a working login:
=
Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7)
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 24 to 127.0.0.1 port 59536
Framed-IP-Address = 141.163.192.64
MS-MPPE-Encryption-Types = 0x0004
MS-MPPE-Encryption-Policy = 0x0002
MS-CHAP2-Success =
0xdb533d43314635413343393031354536343336343346313837304135454345383546444545363443433432
Reply-Message = "Yes"
MS-MPPE-Recv-Key = 0xdbeaf9748e2221f03f521d891346d33f
MS-MPPE-Send-Key = 0xc346ea6996ae8388f9de48e0f2fa0434
Finished request 0.
=
For a failed login:
=
Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7)
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 27 to 127.0.0.1 port 53597
Framed-IP-Address = 141.163.192.64
MS-MPPE-Encryption-Types = 0x0004
MS-MPPE-Encryption-Policy = 0x0002
Reply-Message = "Yes"
MS-MPPE-Recv-Key = 0xa6f4391a49e2df2088d8807bd929eef6
MS-MPPE-Send-Key = 0x1d8311b17d07f5a1be38f07abe1211e3
Finished request 3.
=
The failed login has no MS-CHAP2-Success attribute being sent back.
John.
--
John Horne Tel: +44 (0)1752 587287
University of Plymouth, UK Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
John Horne wrote: > The problem seems to be that although the proxy server returns a 'Yes' > reply (meaning the user is authenticated) What does that mean? There is no standard attribute to transport a "Yes". > Although this looks like a pppd problem, it only occurs after we have > issued 'radmin -e hup'. If we don't use the control-socket, or just use > it without issuing a 'hup', then pppd works fine. Use tcpdump to see what the Access-Accepts look like before && after the HUP. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Wed, 2010-09-22 at 15:15 +0200, Alan DeKok wrote: > I've put some preliminary tar files on: > > http://git.freeradius.org/pre/ > > If there are any issues, let me know now. > We have an issue but I am a little lost as to where things are going wrong. If I set the uid/gid and 'mode=rw' in control-socket, and then restart the radiusd process, all is okay. However, if I then run 'radmin -e hup', the radius log file shows the re-reading of the config file and modules being reloaded, but *some* of our users cannot then authenticate. The server provides authentication for both wireless users and VPN users. For wireless users the wireless lan controller talks to the radius server, and the server proxies the request on to a backed IAS server. This works fine in all instances. The VPN users take a slightly different route in that they use a PPTP connection, which calls a PPP radius.so object. This in turn accesses the radius server (which is running on the same host), and that proxies the request off as with wireless users. The problem seems to be that although the proxy server returns a 'Yes' reply (meaning the user is authenticated) for the VPN users, the pppd process does not seem to recognise it and treats it as a failed CHAP authentication. As such what we see is the radius log saying the user has authenticated okay, but the user receives a 691 (I think) code indicating that there is a problem with their userid/password. Why this only occurs when we use 'radmin -e hup' I don't know. I can only guess that maybe something isn't being reloaded. If we do not use the control-socket then it all works fine for all our users. I have - finally - got this working (or rather failing) on a test server. So I can try to tackle the problem without affecting our live servers. A small log file snippet from the server: The radius log shows (having just issued 'radmin -e hup'): Wed Sep 22 16:41:57 2010 : Info: Received HUP signal. Wed Sep 22 16:41:57 2010 : Info: HUP - Re-reading configuration files Wed Sep 22 16:41:57 2010 : Info: HUP - loading modules Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "suffix" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "acct_log" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.post-proxy" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "radutmp" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "suffix" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.post-proxy" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.access_reject" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.accounting_response" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "radutmp" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "pap" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "files" Wed Sep 22 16:41:57 2010 : Info: Loaded virtual server inner-tunnel Wed Sep 22 16:41:57 2010 : Info: Loaded virtual server Wed Sep 22 16:41:57 2010 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Wed Sep 22 16:42:38 2010 : Auth: Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7) However, our daemon log file shows: Sep 22 16:42:37 jhvm1 pppd[27048]: rcvd [CHAP Response id=0xd3 <4a95b44a8179d661b7dc7036d88274d0b309bacedf503df09b5c81ed196320a2c3a6accc68c1f70600>, name = "jhorne"] Sep 22 16:42:38 jhvm1 pppd[27048]: Yes Sep 22 16:42:38 jhvm1 pppd[27048]: Peer jhorne failed CHAP authentication Sep 22 16:42:38 jhvm1 pppd[27048]: sent [CHAP Failure id=0xd3 "Yes\n"] Sep 22 16:42:38 jhvm1 pppd[27048]: sent [LCP TermReq id=0x2 "Authentication failed"] The 'Yes' is returned by the proxy server. For some reason pppd is logging this and treating it as a chap failure. Normally it does not log the reply as text, but instead sends a chap response: Sep 22 16:45:00 jhvm1 pppd[27176]: rcvd [CHAP Response id=0xc8 , name = "jhorne"] Sep 22 16:45:00 jhvm1 pppd[27176]: sent [CHAP Success id=0xc8 "S=B18D5D0EC139ECCB0D17EBADF2DE818BCD7DF55B"] Although this looks like a pppd problem, it only occurs after we have issued 'radmin -e hup'. If we don't use the control-socket, or just use it without issuing a 'hup', then pppd works fine. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On 22/09/10 15:14, Phil Mayers wrote: On 22/09/10 14:15, Alan DeKok wrote: I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. Can we squeeze one quick VSA update into dictionary.extreme: ATTRIBUTE Extreme-Netlogin-Extended-Vlan 211 string ...it's documented in the XOS concepts guide and we use it successfully here; format is: Uuntagged;Ttagged;..;TtaggedN Wait never mind; it's in there already! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On 22/09/10 14:15, Alan DeKok wrote: I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. Can we squeeze one quick VSA update into dictionary.extreme: ATTRIBUTE Extreme-Netlogin-Extended-Vlan 211 string ...it's documented in the XOS concepts guide and we use it successfully here; format is: Uuntagged;Ttagged;..;TtaggedN - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Garber, Neal wrote: >> Last call for 2.1.10 > > I haven't had a chance to rework the patch for saving replies after a > PEAP/TTLS reject (been very busy at work). I'll try to get to it today; but, > I assume it's too late for 2.1.10 at this point, right? I'll take a look... but 2.1.10 has been pending for a long time. :( Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Last call for 2.1.10
> Last call for 2.1.10 I haven't had a chance to rework the patch for saving replies after a PEAP/TTLS reject (been very busy at work). I'll try to get to it today; but, I assume it's too late for 2.1.10 at this point, right? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Last call for 2.1.10
I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. The changelog is *extensive*. There are a large number of minor bugs fixed, and a lot of minor new features added. But the result is that the server has taken a significant step ahead in usability and functionality. Thanks to everyone for testing intermediate releases. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Hi, This was noted the other day. I committed a fix, and just pushed it back to the git repositories. Thanks. Re-pulled, compiled, installed, works with test requests. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On 2010/08/12 10:02 AM, Alan DeKok wrote: Stefan Winter wrote: libeap/.libs/libfreeradius-eap.so: undefined reference to `radius_pairmake' This was noted the other day. I committed a fix, and just pushed it back to the git repositories. I can confirm that it compiles on Debian Lenny now. Not tested it though. -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Stefan Winter wrote: > libeap/.libs/libfreeradius-eap.so: undefined reference to `radius_pairmake' This was noted the other day. I committed a fix, and just pushed it back to the git repositories. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On 2010/08/12 09:36 AM, Stefan Winter wrote: /root/freeradius-server-2.1.10-pre/src/lib/.libs/libfreeradius-radius.so -lnsl -lresolv -lpthread -lssl -lcrypto -Wl,-rpath -Wl,/usr/local/freeradius/2.1.10-pre/lib libeap/.libs/libfreeradius-eap.so: undefined reference to `radius_pairmake' collect2: ld returned 1 exit status gmake[6]: *** [radeapclient] Fehler 1 gmake[6]: Leaving directory `/root/freeradius-server-2.1.10-pre/src/modules/rlm_eap' Hi, Debian Lenny. 1) Please remember to update debian/changelog to 2.1.10 2) Same compile error: gcc -o .libs/radeapclient .libs/radeapclient.o libeap/.libs/libfreeradius-eap.so -lnsl -lresolv -lpthread -lssl -lcrypto -Wl,--rpath -Wl,/usr/lib/freeradius libeap/.libs/libfreeradius-eap.so: undefined reference to `radius_pairmake' collect2: ld returned 1 exit status make[7]: *** [radeapclient] Error 1 make[7]: Leaving directory `/usr/src/freeradius-2.1.10-git/freeradius-server/src/modules/rlm_eap' make[6]: *** [rlm_eap] Error 2 Cheers, -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
Hi, I've just tried to compile with my usual set of configure flags, and got: /usr/bin/libtool --mode=link gcc -o radeapclient radeapclient.lo libeap/libfreeradius-eap.la -lnsl -lresolv -lpthread -lcrypto -lssl -lcrypto libtool: link: gcc -o .libs/radeapclient .libs/radeapclient.o libeap/.libs/libfreeradius-eap.so /root/freeradius-server-2.1.10-pre/src/lib/.libs/libfreeradius-radius.so -lnsl -lresolv -lpthread -lssl -lcrypto -Wl,-rpath -Wl,/usr/local/freeradius/2.1.10-pre/lib libeap/.libs/libfreeradius-eap.so: undefined reference to `radius_pairmake' collect2: ld returned 1 exit status gmake[6]: *** [radeapclient] Fehler 1 gmake[6]: Leaving directory `/root/freeradius-server-2.1.10-pre/src/modules/rlm_eap' in the middle of the build. System is openSUSE 11.1 32-Bit, gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) My configure flags are: ./configure --sysconfdir=/usr/local/freeradius/config/ --prefix=/usr/local/freeradius/2.1.10-pre --with-system-libtool Changing these to use built-in libtool does not change anything: gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/root/freeradius-server-2.1.10-pre/src -Ilibeap -c radeapclient.c -o radeapclient.o >/dev/null 2>&1 /root/freeradius-server-2.1.10-pre/libtool --mode=link gcc -o radeapclient radeapclient.lo libeap/libfreeradius-eap.la -lnsl -lresolv -lpthread -lcrypto -lssl -lcrypto gcc -o .libs/radeapclient .libs/radeapclient.o libeap/.libs/libfreeradius-eap.so -lssl -lcrypto -lnsl -lresolv -lpthread -Wl,--rpath -Wl,/usr/local/freeradius/2.1.10-pre/lib libeap/.libs/libfreeradius-eap.so: undefined reference to `radius_pairmake' collect2: ld returned 1 exit status gmake[6]: *** [radeapclient] Fehler 1 gmake[6]: Leaving directory `/root/freeradius-server-2.1.10-pre/src/modules/rlm_eap' Greetings, Stefan Winter Am 08.08.2010 23:14, schrieb Alan DeKok: Version 2.1.10 should be released soon. If there are any pressing issues people would like to get addressed, now is the time to speak up. The proposed change log is available online at: http://github.com/alandekok/freeradius-server/blob/v2.1.x/doc/ChangeLog There are a number of feature improvements in what's supposed to be a "stable" release. These improvements are limited to documentation updates, and changes to the client programs to make them easier to use. The main benefit most people should see is that radclient and radtest now make it easier to send MS-CHAP requests. The server now also listens on 127.0.0.1:18120 for the "inner-tunnel" virtual server. These two changes mean that the "inner-tunnel" portion of PEAP can be tested using nothing more than radtest&& a default server installation. This should help people debug PEAP issues. i.e. They can avoid the issue of "but it works with radtest", when their passwords aren't compatible with MS-CHAP. There only major thing missing now is a DHCP pool allocation strategy. There's been more interest recently in using FreeRADIUS as a DHCP server, so patches to help would be most welcome. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
