> Oct 30 14:14:56 radius freeradius[5524]: TLS section "tls" missing,
trying to use legacy configuration
i.e. you edited the default "eap" module configuration to *remove* the
"tls" configuration.
Then tried to use the "eap-tls" method.
And wondered why it didn't work.
Here's the solution:
Fix pushed https://github.com/FreeRADIUS/freeradius-
server/commit/beb1351d682ab6f1170cc60ce7ca05f597e5d7d6
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1962046
Title:
DEP8: test more auth
3.0.26 isn't released. But if the git "head" of v3.0.x crashes, that's
bad.
Perhaps you could include back trace from gdb?
FreeRADIUS also includes tests for various authentication types, but it
doesn't include tests with radclient for MS-CHAP
--
You received this bug notification because you
The solution is well documented in FreeRADIUS. Just change the "pool"
section of the "sql" module configuration. Set "start = 0"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1081509
Title:
We'll try to get it out this week.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1955009
Title:
Freeradius 3.0.21+dfsg-3build1 fails test of moonshot-gss-eap
To manage notifications about this bug
> So I now understand the OR change, just not why content_type is
compared with UINT8_MAX.
The TLS specification (RFC 8446, among others) says that the ContentType
field is an 8-bit value.
Therefore anything past that is not a real content type, and is
"invented" by OpenSSL.
--
You received
There are a LOT of changes required to get FreeRADIUS working with
OpenSSL3.
We will be releasing 3.0.26 in January to address these, and other
issues. I'd suggest waiting for that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I would suggest trying 3.0.25. If that works, don't even bother trying
to debug this. OpenSSL has minor behavior differences across a major
version change.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
My $0.02 is to try the head of v3.0.x. I don't recall if we put in
fixes specifically for OpenSSL 3, but perhaps.
We've also *significantly* updated the TLS debugging output. It's a lot
clearer, and gives a lot more information.
--
You received this bug notification because you are a member
> Sadly, there are RADIUS servers which suffer from TLS version
intolerance and will refuse authentication when the client offers TLS
1.3
This statement is completely missing the point. There are *no standards
available* for using TLS 1.3 with *any* EAP method. The IETF is working
on them, but
Fixes committed in v3.0.x:
https://github.com/FreeRADIUS/freeradius-
server/commit/2125490c92c29356cd1564080fe9dc1e05acf8e3
and in master branch:
https://github.com/FreeRADIUS/freeradius-
server/commit/1334cf5942dcf46fe0ad99a2381604b42a35b331
We won't do the v2.0.x branch, as that release is
> So it works, and I assume the freeradius documentation is not supposed
to include explanations about a chroot?
You're free to submit documentation. Either to the project itself, or
to http://wiki.freeradius.org
> Just for some reason, FreeBSD version works fine with user=freerad
group=freerad
Ubuntu is free to create a patch themselves. For us, v2 is EOL, and
has been EOL for over a year. We encourage everyone to upgrade to v3,
which has all of the relevant fixes included. And, which has many more
features.
i.e. if you're going to upgrade OpenSSL to a new release, you might as
You haven't said which version of the server this is for.
If it's the ubuntu one, it's 2.1.12. That is YEARS out of date.
There is no reason to track down a bug in a version that old.
As the FreeRADIUS author, I suggest trying 2.2.4. It was released
yesterday.
--
You received this bug
You haven't said which version of the server this is for.
If it's the ubuntu one, it's 2.1.12. That is YEARS out of date.
There is no reason to track down a bug in a version that old.
As the FreeRADIUS author, I suggest trying 2.2.4. It was released
yesterday.
--
You received this bug
Maxxer wrote:
libtool: compile: 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
Maxxer wrote:
libtool: compile: 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
Mark Schouten wrote:
It is impossible to bind freeradius in Ubuntu to :: (ipv6 any). This
seems to be a known bug for about three years [1]. Please look into
this. Might be nice if this is fixed before Precise, which will
definitly run in IPv6 only environments in it's support lifecycle.
It
Mark Schouten wrote:
It is impossible to bind freeradius in Ubuntu to :: (ipv6 any). This
seems to be a known bug for about three years [1]. Please look into
this. Might be nice if this is fixed before Precise, which will
definitly run in IPv6 only environments in it's support lifecycle.
It
Stas Sușcov wrote:
Anybody knows if it's worth rebuilding the package using lucid sources?
Otherwise I'm leaving it like it is.
Later versions of FreeRADIUS have fixes.
I suggest leaving the current 2.1.0 version alone, and ugprading
instead.
--
freeradius with openssl support doesn't
Stas Sușcov wrote:
Anybody knows if it's worth rebuilding the package using lucid sources?
Otherwise I'm leaving it like it is.
Later versions of FreeRADIUS have fixes.
I suggest leaving the current 2.1.0 version alone, and ugprading
instead.
--
freeradius with openssl support doesn't
Ah... localhost likely means ::1, or IPv6 transport.
If the OS supplies the header files, but doesn't have the code to
implement the feature, then that's likely the error you'll get.
The simplest thing to do is to disable udpfromto via the configure
script.
--
radclient doesn't work
Ah... localhost likely means ::1, or IPv6 transport.
If the OS supplies the header files, but doesn't have the code to
implement the feature, then that's likely the error you'll get.
The simplest thing to do is to disable udpfromto via the configure
script.
--
radclient doesn't work
It's a bug in libltdl that is in Ubuntu.
See /usr/include/ltdl.h on the affected system. It has a line:
#define lt_preloaded_symbolslt__PROGRAM__LTX_preloaded_symbols
Q: Where is lt__PROGRAM__LTX_preloaded_symbols defined or referenced?
A: Nowhere.
If you spend some time spelunking
It's a bug in libltdl that is in Ubuntu.
See /usr/include/ltdl.h on the affected system. It has a line:
#define lt_preloaded_symbolslt__PROGRAM__LTX_preloaded_symbols
Q: Where is lt__PROGRAM__LTX_preloaded_symbols defined or referenced?
A: Nowhere.
If you spend some time spelunking
It looks like a conflict between the ltdl.h / libltld.a included on the
system, and the ones included with the server. Due to magic issues
with libtool, it can compile using the local files, and then link to the
global files. Hence the conflict.
In version 2.1.7 (to be released soon), we've
It looks like a conflict between the ltdl.h / libltld.a included on the
system, and the ones included with the server. Due to magic issues
with libtool, it can compile using the local files, and then link to the
global files. Hence the conflict.
In version 2.1.7 (to be released soon), we've
Thierry Carrez wrote:
** Changed in: freeradius (Ubuntu)
Importance: Undecided = High
** Changed in: freeradius (Ubuntu)
Status: New = Confirmed
** Changed in: freeradius (Ubuntu)
Assignee: (unassigned) = Thierry Carrez (ttx)
See also later versions of FreeRADIUS. This
Thierry Carrez wrote:
** Changed in: freeradius (Ubuntu)
Importance: Undecided = High
** Changed in: freeradius (Ubuntu)
Status: New = Confirmed
** Changed in: freeradius (Ubuntu)
Assignee: (unassigned) = Thierry Carrez (ttx)
See also later versions of FreeRADIUS. This
OK. I've put similar patches into git head (stable master branches).
They should be in the next major release of the server (2.1.4)
--
freeradius upgrade broken in hardy backports
https://bugs.launchpad.net/bugs/315896
You received this bug notification because you are a member of Ubuntu
Bugs,
Performing automated upgrades across major revision numbers of a program
isn't recommended.
There are a large number of changes in the configuration files and in
their processing from version 1.1.x to version 2.1.x. Writing scripts
to do automated upgrades is extremely difficult. The upgrade
Performing automated upgrades across major revision numbers of a program
isn't recommended.
There are a large number of changes in the configuration files and in
their processing from version 1.1.x to version 2.1.x. Writing scripts
to do automated upgrades is extremely difficult. The upgrade
not only at the problem, but at the attitude of the
package maintainers who seem to be saying just step through a bunch of
poorly documented hoops to work around our lying package.
Alan DeKok.
--
libperl.so doesn't exist, and perl -MExtUtils::Embed -e ldopts outputs
-lperl
https
Public bug reported:
Binary package hint: libperl5.8
$ locate libperl
...
/var/lib/dpkg/info/libperl5.8.shlibs
/usr/lib/libperl.so.5.8
/usr/lib/libperl.so.5.8.8
/usr/share/defoma/libperl-file.pl
...
There's no libperl.a, and no libperl.so
$ perl -MExtUtils::Embed -e ldopts
-Wl,-E
34 matches
Mail list logo
