Am 30.08.19 um 19:02 schrieb Munroe Sollog:
Ah, looking ~150 lines down in the changelog.Debian.gz I see a note about it being disabled in 3.0.12. Maybe the patch Debian added could have also added some diagnostic output when someone tries to enable it perhaps preventing a few days of wasted time.
That was the Debian way to deal with the auth bypass issue that had popped up with tls_cache in 3.0.14 (AFAIR): They try to backport delta patches to _whatever_ version Debian stable is shipping at the time (here: 3.0.12). AFAIK, Ubuntu in turn draws on the Debian packages, but tries to provide newer versions, i.e. 3.0.17 here. Looks newer, but seemingly has inherited Debians "fix". So you end up with a pseudo-3.0.17 that has tls_cache disabled the hard way while upstream things had been fixed very qickly in FR 3.0.15. One could get the impression that certain FR developers don't like this too much cf. a similar discussion about openssl issues: http://lists.freeradius.org/pipermail/freeradius-users/2017-September/088774... http://lists.freeradius.org/pipermail/freeradius-users/2017-September/088784... Watching this pseudo-3.0.17 thing really makes me think Alan&Alan are plain right. While using Debian/Ubuntu as a base might save you some hassles, there are serious limits to their approach. To run a productive FR server, either compile yourself or get .debs from https://networkradius.com/freeradius-packages/ Cheers, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg