Parse error freeradius-1.1.1
Hi all, I try to compile freeradius-1.1.1 on a Suse Linux 8 Enterprise Server with gcc-3.2.2 and get the following error message: In file included from eap_peap.h:25, from rlm_eap_peap.c:24: ../../libeap/eap_tls.h:138: parse error before SSL ./../libeap/eap_tls.h:138: warning: no semicolon at end of struct or union ./../libeap/eap_tls.h:141: parse error before '*' token ... What could be wrong? Best regards Margit Meyer - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Parse error freeradius-1.1.1
Margit Meyer wrote: I try to compile freeradius-1.1.1 on a Suse Linux 8 Enterprise Server with gcc-3.2.2 and get the following error message: In file included from eap_peap.h:25, from rlm_eap_peap.c:24: ../../libeap/eap_tls.h:138: parse error before SSL ./../libeap/eap_tls.h:138: warning: no semicolon at end of struct or union ./../libeap/eap_tls.h:141: parse error before '*' token ... What could be wrong? There is a few problems in the autoconf tests in version 1.1.1. Please try 1.1.2. -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Parse error freeradius-1.1.1
RE version 1.1.2I'm currious. I have tried compiling 1.1.2 on Solaris 10, OpenBSD 3.9, and Debian Sid. The ONLY way I have been able to get it working is with the deb packages. I have read exchanges regarding autoconf and libtool issues on the dev list. The most recent CVS snapshots progress further in the build, but still result in errors. Any news on when the issues may be resolved, perhaps a 1.1.3 release? I'm not an uber compiler, so I admit I am a bit weak at resolving compiletime issues. Under Solaris 10, my true target platform, I get the following final output error from the build attempt (I have already rebuilt the headers under Solaris 10 which is a common problem when compiling under that OS.)...In file included from dict.c:42:../include/libradius.h:316: error: conflicting types for `closefrom' /usr/include/stdlib.h:193: error: previous declaration of `closefrom'make[4]: *** [dict.lo] Error 1I am trying to move our enterprise RADIUS to freeradius from a comercial product, but I need a documented install process that works well. Any ideas? Thanks,LinOn 6/21/06, Nicolas Baradakis [EMAIL PROTECTED] wrote: Margit Meyer wrote: I try to compile freeradius-1.1.1 on a Suse Linux 8 Enterprise Server with gcc-3.2.2 and get the following error message: In file included from eap_peap.h:25, from rlm_eap_peap.c:24: ../../libeap/eap_tls.h:138: parse error before SSL ./../libeap/eap_tls.h:138: warning: no semicolon at end of struct or union ./../libeap/eap_tls.h:141: parse error before '*' token ... What could be wrong?There is a few problems in the autoconf tests in version 1.1.1.Please try 1.1.2.--Nicolas Baradakis-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: Parse error freeradius-1.1.1
Lin Richardson [EMAIL PROTECTED] wrote: I'm currious. I have tried compiling 1.1.2 on Solaris 10, OpenBSD 3.9, and Debian Sid. The ONLY way I have been able to get it working is with the deb packages. The Debian people actively maintain updated packages for FreeRADIUS. Plus, it's difficult for open source projects to compile test the project on many platforms, because they may not have access to many platforms. In file included from dict.c:42: ../include/libradius.h:316: error: conflicting types for `closefrom' /usr/include/stdlib.h:193: error: previous declaration of `closefrom' Add the following line at the top of libradius.h, and the build should succeed: #define HAVE_CLOSEFROM 1 Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy - EAP problems
Wladyslaw Pietraszek [EMAIL PROTECTED] wrote: Authentication when access-points use 'pdc' directly works fine for EAP-PEAP/TTLS. Authentication for the topology access-point - proxy - pdc fails. Probably supplicant/access-point ignores access-challenge (EAP) response. The reason that happens is most likely that the proxy server certificates don't contain the magic Microsoft OID's. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Parse error freeradius-1.1.1
On Wed, Jun 21, 2006 at 10:28:12AM -0600, Lin Richardson said: RE version 1.1.2 I'm currious. I have tried compiling 1.1.2 on Solaris 10, OpenBSD 3.9, and Debian Sid. The ONLY way I have been able to get it working is with the deb packages. I have read exchanges regarding autoconf and libtool issues on the dev list. The most recent CVS snapshots progress further in the build, but still result in errors. Any news on when the issues may be resolved, perhaps a 1.1.3 release? I'm not an uber compiler, so I admit I am a bit weak at resolving compiletime issues. Under Solaris 10, my true target platform, I get the following final output error from the build attempt (I have already rebuilt the headers under Solaris 10 which is a common problem when compiling under that OS.) ... In file included from dict.c:42: ../include/libradius.h:316: error: conflicting types for `closefrom' /usr/include/stdlib.h:193: error: previous declaration of `closefrom' make[4]: *** [dict.lo] Error 1 I am trying to move our enterprise RADIUS to freeradius from a comercial product, but I need a documented install process that works well. Any ideas? debian maintainer hat on Take a look at debian/rules in the source package for debian. It is the debian Makefile, and contains anything extra we do to make it build nicely. The closefrom error sounds symptomatic of some of the autotools problems I have been looking at. The relevant lines are: #ifndef HAVE_CLOSEFROM int closefrom(int fd); #endif But clearly there is a system closefrom, so either the macro is undefined, or the configure test missed the system one. Try adding #undef HAVE_CLOSEFROM to src/include/autoconf.h.in, and rerunning the build, at a guess. For this reason and others, I am looking at reworking a bunch of the auto* scripts, and hope they will be acceptable upstream. They all need updating, and some of them can be considerably streamlined, but I don't know how invasive I/you want to be. One of the first things I see is that there are multiple configure scripts in subdirectories, and this is usually not what you want - it's usualy easier to add the tests to the top level configure script and source the config.h from the top level. But again, I've just started looking - there may be reasons (historical or otherwise) for this that I'm not seeing yet. Any tips or pointers greatly appreciated. Take care, -- -- | Stephen Gran | Decision maker, n.: The person in your | | [EMAIL PROTECTED] | office who was unable to form a task| | http://www.lobefin.net/~steve | force before the music stopped.| -- signature.asc Description: Digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
post-proxy
Hi, What i would like to do is send an attribute in the radius answer but only for proxied request. When the reply comes back from a distant radius server, I would like to add something like : Filter-ID = Enterasys:version=1:policy=test. But i want to add this only for proxied users which means i cannot use (I suppose) the users file. is there a way to do it? Thank you. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re-write Attributes based upon NAS-Port-Type and LDAP authorization response
Hello Folks, I've posted something similar to this in the past and my question was answered rather tersely. I'm hoping a little more detail will invoke the type of kind responses I'm used to in the Open Source Community. I've got FreeRadius on RedHat ES3 authenticating users to OpenLDAP. So far we've simply been authenticating users via 802.1x on Wired Switch ports and we've now added new equipment for WIFI which requires the RFC3580 attributes (instead of the Filter-ID we've populated in our LDAP schema). I believe it should be relatively simple to perform the following check's to re-write my attributes for the WIFI Gear. I can base the decision to re-write on the NAS-Port-Type received. My pseudo-code thought process is outlined below (I'm not a coder, would never profess to be; thus my post!): if NAS-Port-Type == Wireless - IEEE 802.11 then Tunnel-Medium-Type == IEEE-802 Tunnel-Type == VLAN if Filter-ID =~ Internet-Restricted then Tunnel-Private-Group-ID == 155 (or the Restricted VLANID) elseif Filter-ID =~ Allow-All then Tunnel-Private-Group-ID == 156 (or the Allowed VLANID). endif endif My reading thus far has lead me to test my reply attribute requirements from the users file and that works perfectly. If someone could point me in a simple direction on how to strip/rewrite the attributes based on the 'authorization' reply from LDAP, I'd be indebted. I've seen examples of profiles stored on LDAP, but I'm curious how I could choose a different profile based upon the NAS-Port-Type received in the Access-Request Here's what I did in the users file to test successfully (I don't know that it's of any value but to demonstrate what I'm trying to accomplish). testuserUser-Password == user,NAS-Port-Type == Wireless-802.11 Tunnel-Medium-Type == IEEE-802, Tunnel-Type == VLAN, Tunnel-Private-Group-Id == 155 testuserUser-Password == user,NAS-Port-Type == Ethernet Filter-ID == Enterasys:version=1:policy=Internet-Restricted admin User-Password == admin, NAS-Port-Type == Wireless-802.11 Tunnel-Medium-Type == IEEE-802, Tunnel-Type == VLAN, Tunnel-Private-Group-Id == 156 admin User-Password == admin, NAS-Port-Type == Ethernet Filter-ID == Enterasys:version=1:policy=Allow-All Thanks to all in advance. Bill - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Parse error freeradius-1.1.1
This was helpful!I progressed beyond the error noted previously by adding #undef HAVE_CLOSEFROM to the src/include/autoconf.h.in file.The build now ends in an error (under Solaris 10) that is similar to the error I hit with my attempts under Debian Sid. ...gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/home/lplricha/src/freeradius-1.1.2/src/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE -c rlm_perl.c -o rlm_perl.o /dev/null 21 mv -f .libs/rlm_perl.lo rlm_perl.lomv: cannot access .libs/rlm_perl.lomake[6]: *** [rlm_perl.lo] Error 2make[6]: Leaving directory `/usr/home/lplricha/src/freeradius-1.1.2/src/modules/rlm_perl' Also, I would be happy to do test compiles under different OS installs. I can't really help with the coding much, but would be happy to contribute in other ways. That may be off-topic for this list though. :)Thanks, LinOn 6/21/06, Stephen Gran [EMAIL PROTECTED] wrote: On Wed, Jun 21, 2006 at 10:28:12AM -0600, Lin Richardson said: RE version 1.1.2 I'm currious.I have tried compiling 1.1.2 on Solaris 10, OpenBSD 3.9, and Debian Sid.The ONLY way I have been able to get it working is with the deb packages. I have read exchanges regarding autoconf and libtool issues on the dev list.The most recent CVS snapshots progress further in the build, but still result in errors.Any news on when the issues may be resolved, perhaps a 1.1.3 release? I'm not an uber compiler, so I admit I am a bit weak at resolving compiletime issues. Under Solaris 10, my true target platform, I get the following final output error from the build attempt (I have already rebuilt the headers under Solaris 10 which is a common problem when compiling under that OS.) ... In file included from dict.c:42: ../include/libradius.h:316: error: conflicting types for `closefrom' /usr/include/stdlib.h:193: error: previous declaration of `closefrom' make[4]: *** [dict.lo] Error 1 I am trying to move our enterprise RADIUS to freeradius from a comercial product, but I need a documented install process that works well.Any ideas?debian maintainer hat onTake a look at debian/rules in the source package for debian.It isthe debian Makefile, and contains anything extra we do to make itbuild nicely.The closefrom error sounds symptomatic of some of the autotools problems I have been looking at.The relevant lines are:#ifndef HAVE_CLOSEFROMint closefrom(int fd);#endifBut clearly there is a system closefrom, so either the macro isundefined, or the configure test missed the system one.Try adding #undef HAVE_CLOSEFROMto src/include/autoconf.h.in, and rerunning the build, at a guess.For this reason and others, I am looking at reworking a bunch of theauto* scripts, and hope they will be acceptable upstream.They all need updating, and some of them can be considerably streamlined, but I don'tknow how invasive I/you want to be.One of the first things I see isthat there are multiple configure scripts in subdirectories, and this is usually not what you want - it's usualy easier to add the tests tothe top level configure script and source the config.h from the top level.But again, I've just started looking - there may be reasons (historical or otherwise) for this that I'm not seeing yet.Any tips or pointersgreatly appreciated.Take care,-- --|Stephen Gran| Decision maker, n.:The person in your | |[EMAIL PROTECTED] | office who was unable to form a task||http://www.lobefin.net/~steve | forcebefore the music stopped.| ---BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFEmX3pSYIMHOpZA44RAoo+AJ9j7vNr/JN8ZeHXNkhDw3en9TJe4gCfbVM0 MhlhpOzCjYl9SN77VeIZP1w==YYof-END PGP SIGNATURE--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: Parse error freeradius-1.1.1
After looking more carefully at the make output, I noticed that the build failed because the rlm_perl.lo had not been built, and the xarch=v8 was what it complained about when it tried to build it. I did some digging and ended up replacing the -x arch=v8 flag with -mcpu=v8 -mtune=ultrasparc in the Makefile found in the directory of the component that was failing in the build.I had encountered a similar error on a previous Solaris/sparc compile and used the same fix. The build was successful after this change. I will test the server for functionality and drop one more note to confirm if all goes well. Regards,LinOn 6/21/06, Lin Richardson [EMAIL PROTECTED] wrote: This was helpful!I progressed beyond the error noted previously by adding #undef HAVE_CLOSEFROM to the src/include/autoconf.h.in file.The build now ends in an error (under Solaris 10) that is similar to the error I hit with my attempts under Debian Sid. ...gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/home/lplricha/src/freeradius-1.1.2/src/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE -c rlm_perl.c -o rlm_perl.o /dev/null 21 mv -f .libs/rlm_perl.lo rlm_perl.lomv: cannot access .libs/rlm_perl.lomake[6]: *** [rlm_perl.lo] Error 2make[6]: Leaving directory `/usr/home/lplricha/src/freeradius-1.1.2/src/modules/rlm_perl' Also, I would be happy to do test compiles under different OS installs. I can't really help with the coding much, but would be happy to contribute in other ways. That may be off-topic for this list though. :)Thanks, LinOn 6/21/06, Stephen Gran [EMAIL PROTECTED] wrote: On Wed, Jun 21, 2006 at 10:28:12AM -0600, Lin Richardson said: RE version 1.1.2 I'm currious.I have tried compiling 1.1.2 on Solaris 10, OpenBSD 3.9, and Debian Sid.The ONLY way I have been able to get it working is with the deb packages. I have read exchanges regarding autoconf and libtool issues on the dev list.The most recent CVS snapshots progress further in the build, but still result in errors.Any news on when the issues may be resolved, perhaps a 1.1.3 release? I'm not an uber compiler, so I admit I am a bit weak at resolving compiletime issues. Under Solaris 10, my true target platform, I get the following final output error from the build attempt (I have already rebuilt the headers under Solaris 10 which is a common problem when compiling under that OS.) ... In file included from dict.c:42: ../include/libradius.h:316: error: conflicting types for `closefrom' /usr/include/stdlib.h:193: error: previous declaration of `closefrom' make[4]: *** [dict.lo] Error 1 I am trying to move our enterprise RADIUS to freeradius from a comercial product, but I need a documented install process that works well.Any ideas?debian maintainer hat onTake a look at debian/rules in the source package for debian.It isthe debian Makefile, and contains anything extra we do to make itbuild nicely.The closefrom error sounds symptomatic of some of the autotools problems I have been looking at.The relevant lines are:#ifndef HAVE_CLOSEFROMint closefrom(int fd);#endifBut clearly there is a system closefrom, so either the macro isundefined, or the configure test missed the system one.Try adding #undef HAVE_CLOSEFROMto src/include/autoconf.h.in, and rerunning the build, at a guess.For this reason and others, I am looking at reworking a bunch of theauto* scripts, and hope they will be acceptable upstream.They all need updating, and some of them can be considerably streamlined, but I don'tknow how invasive I/you want to be.One of the first things I see isthat there are multiple configure scripts in subdirectories, and this is usually not what you want - it's usualy easier to add the tests tothe top level configure script and source the config.h from the top level.But again, I've just started looking - there may be reasons (historical or otherwise) for this that I'm not seeing yet.Any tips or pointersgreatly appreciated.Take care,-- --|Stephen Gran| Decision maker, n.:The person in your | |[EMAIL PROTECTED] | office who was unable to form a task|| http://www.lobefin.net/~steve | forcebefore the music stopped.| ---BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFEmX3pSYIMHOpZA44RAoo+AJ9j7vNr/JN8ZeHXNkhDw3en9TJe4gCfbVM0 MhlhpOzCjYl9SN77VeIZP1w==YYof-END PGP SIGNATURE--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: Parse error freeradius-1.1.1
Lin Richardson [EMAIL PROTECTED] wrote: The build now ends in an error (under Solaris 10) that is similar to the error I hit with my attempts under Debian Sid. If you're not going to use rlm_perl, just delete that directory. Alan Dekok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
PEAP Auth
Title: Message Hello, I am attempting to use the latest Debian build with Freeradius and cannot seem to get PEAP/TLS/TTLS to work. I have even gone as far as reloading the box fresh and installing the sources of OpenSSL and then Freeradius. I still get the same error message on startup regarding no file for TLS. I have searched the Debian site, the Freeradius site, and the web in general and cannot seem to find out how to fix this. Does anyone know? Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_exec
Hello everybody, does anyone knows what rlm_exec module does? Thanks, -- Leandro Pereira de Lima e Silva http://www.vialink.com.br/ A verdadeira medida do caráter de um homem é o que ele faria se soubesse que nunca seria descoberto. -- Thomas B. Macaulay - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alvarion Accounting with free radius
I am writing to see if anyone on the list is using Alvarion breezeAcess radios with free radius for accounting? If can you give me a helping hand, I am trying to get freeradius to understand what the radios is sending and have it mapped the attributes to the right sql fields. I can send some debug data if needed . We are in Russia working on a project for schools kids and the orphanges and we need ot account trafice with our network of Alvarion radios -- Robert Dukes - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: error: Installed (but unpackaged) files(s) found: on REDHAT Enterprise 4.0 (RHEL4) and FreeRadius 1.1.2
Hello, I'm struggling to build a RPM package on RHEL 4 also (based on freeradius.spec file), I have tried adding sed line as suggested in on of the previous posts and also suggested %doc lines, but with no success. How do i have to modify freeradius.spec file to build it successfully? Has anyone (besides Alberto Cruz) also managed to build RPM on RHEL 4? Thanky for any info, Tadej Bregar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: error: Installed (but unpackaged) files(s) found: onREDHAT Enterprise 4.0 (RHEL4) and FreeRadius 1.1.2
Use the rpms found on the RHEL cds or you could get an updated rpm from the centos or fedora core 5 cds/dvd. That's the most logical thing I'd do without building from the original source -Original Message- From: Tadej Bregar [mailto:[EMAIL PROTECTED] Sent: 21 June 2006 23:33 To: freeradius-users@lists.freeradius.org Subject: Re: error: Installed (but unpackaged) files(s) found: onREDHAT Enterprise 4.0 (RHEL4) and FreeRadius 1.1.2 Hello, I'm struggling to build a RPM package on RHEL 4 also (based on freeradius.spec file), I have tried adding sed line as suggested in on of the previous posts and also suggested %doc lines, but with no success. How do i have to modify freeradius.spec file to build it successfully? Has anyone (besides Alberto Cruz) also managed to build RPM on RHEL 4? Thanky for any info, Tadej Bregar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Parse error freeradius-1.1.1
On Wed, Jun 21, 2006 at 02:06:02PM -0600, Lin Richardson said: After looking more carefully at the make output, I noticed that the build failed because the rlm_perl.lo had not been built, and the xarch=v8 was what it complained about when it tried to build it. I did some digging and ended up replacing the -xarch=v8 flag with -mcpu=v8 -mtune=ultrasparc in the Makefile found in the directory of the component that was failing in the build. I had encountered a similar error on a previous Solaris/sparc compile and used the same fix. The build was successful after this change. I will test the server for functionality and drop one more note to confirm if all goes well. Thank you for this point of information. This sounds like more libtool/autoconf breakage, at first glance. When (if!) I/we can port the current autotools build system to a newer version, do you mind testing it? Thanks, -- -- | Stephen Gran | Having nothing, nothing can he lose.| | [EMAIL PROTECTED] | -- William Shakespeare, Henry VI | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
