On Jul 16, 2024, at 4:14 PM, Seth Arnold <2073...@bugs.launchpad.net> wrote:
> When playing with the shell script I thought I noticed patterns in the last
> character of the output so I investigated further to make sure that these are
> actually emitting roughly what we expect:
Due to the way
TBH the simplest thing to do is just to drop the rad secret program.
It not used for anything, and is just a helper script.
> On Jul 16, 2024, at 1:35 PM, Andreas Hasenack <2073...@bugs.launchpad.net>
> wrote:
>
> The freeradius update to 3.2.5 enabled a new binary and two new modules,
> as par
> 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: don'
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 algorith
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:
freera
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 thi
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.
htt
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.
https://bugs.launchpad.net/bug
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 of
> 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 t
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 EO
> 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
wel
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 not
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
> -I
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.
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 c
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
https:/
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 thro
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 a
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 FreeRAD
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 pro
rite the additional autoconf checks for
every application that needs libperl.
I'm annoyed 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 D
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 -L/usr/lo
27 matches
Mail list logo
