FreeRADIUS 3 package will not start

PFbest

Run
radiusd -X
from console and post the output.

Huge thanks man! ;D ;D ;D
Got this from console
Guess I could dive into those files, my guess is it's due to upgrade?
The conf file must be from V2, so probably it's not compatible with V3?
:)

FreeRADIUS Version 3.0.15
Copyright (C) 1999-2017 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
Starting - reading configuration files ...
including dictionary file /usr/local/share/freeradius/dictionary
including dictionary file /usr/local/share/freeradius/dictionary.dhcp
including dictionary file /usr/local/share/freeradius/dictionary.vqp
including dictionary file /usr/local/etc/raddb/dictionary
including configuration file /usr/local/etc/raddb/radiusd.conf
including configuration file /usr/local/etc/raddb/clients.conf
/usr/local/etc/raddb/clients.conf[20]: Parse error after "f": unexpected token "<"
Errors reading or parsing /usr/local/etc/raddb/radiusd.conf

doktornotor

What's in /usr/local/etc/raddb/clients.conf? (line 20, but post some context as well).

PFbest

@doktornotor:

What's in /usr/local/etc/raddb/clients.conf? (line 20, but post some context as well).

mmmm, Interesting

line 20 is this: secret = A<103.,c-!:@=1;d,f<@># <dkg1nc-1 It must be improper character escape bug I assume? Since it's working under V2
;)</dkg1nc-1

PFbest

Fixed secret, now I have new error with radiusd -X

tls: Failed reading Trusted root CA list "/usr/local/etc/raddb/certs/ca_cert.pem"
tls: error:0906D066:PEM routines:PEM_read_bio:bad end line
tls: error:0B084009:x509 certificate routines:X509_load_cert_crl_file:PEM lib
rlm_eap_tls: Failed initializing SSL context
rlm_eap (EAP): Failed to initialise rlm_eap_tls
/usr/local/etc/raddb/mods-enabled/eap[2]: Instantiation failed for module "eap"

:o

doktornotor

No idea what you have there in ca_cert.pem. It's supposed to end with


-----END CERTIFICATE-----

PFbest

@doktornotor:

No idea what you have there in ca_cert.pem. It's supposed to end with
-----END CERTIFICATE-----

Weird, my CA was the default one, generated when pfsense was installed

PFbest

Interesting.

After dig into the CA.

I found that the CA file was cut off at the end, like several lines are missing.

After I copied back the complete CA content, everything rocks again. ;D ;D

That's something new to know I guess.

Thanks very much guys!

Cheers!!!

doktornotor

OK… No idea how the CA file got corrupted, the package just uses whatever is saved as a selected CA certificate in config.xml.

PFbest

@doktornotor:

OK… No idea how the CA file got corrupted, the package just uses whatever is saved as a selected CA certificate in config.xml.

I know, it's weird.
I don't even know when it gets corrupted.
At least now I know there is one more thing need to be aware of when freeradius goes wrong.

;)

doktornotor

One more thing - can you test the shared secret like this?

'A<103.,c-!:@=1;d,f<@># <dkg1nc-1' (Save and check whether RADIUS is still running.)</dkg1nc-1'

PFbest

@doktornotor:

One more thing - can you test the shared secret like this?

'A<103.,c-!:@=1;d,f<@># <dkg1nc-1' (Save and check whether RADIUS is still running.)</dkg1nc-1'

Like put exactly 'A<103.,c-!:@=1;d,f<@>#

doktornotor

Yes.

PFbest

@doktornotor:

Yes.

Errrr, guess it won't work?
Cause it's over 31 characters :o

doktornotor

It should still stay 31 characters, just avoid the misparsing issues. See man unlang regarding the single quotes. The single quotes shouldn't count as part of the secret.

PFbest

@doktornotor:

It should still stay 31 characters, just avoid the misparsing issues. See man unlang regarding the single quotes. The single quotes shouldn't count as part of the secret.

Ummmmmm
It returns error as in image

nas.png_thumb

doktornotor

Eh, well… edit this line to 33. I just wanted you to test whether it stops breaking the config, that's all.

PFbest

@doktornotor:

Eh, well… edit this line to 33. I just wanted you to test whether it stops breaking the config, that's all.

Cool, tested.
Results are:

doktornotor

Yes, as said, the secret does not really change. I'll do a PR to add single quotes around the secret automatically so that you can input it without quotes in both the AP and pfSense.

https://redmine.pfsense.org/issues/7836
https://github.com/pfsense/FreeBSD-ports/pull/415

PiBa

Thanks doktornotor 8)
One question though, can a single quote (or backslash) be part of the secret? And if so, should it also be escaped.?.
Found this http://networkradius.com/doc/3.0.10/raddb/syntax/data_string.html but not sure its about the exact same software.

Example
'a string with spaces'
'a string with \'quotes\' in it'
'a string with a backslash \\ in it'

Um ok, reading your pullrequest while writing this i realize your asking the enduser to do this, but then the check for 31 characters should perhaps also allow more characters.?. Wouldnt it be easier to let the code writing the config file do the proper escaping?

doktornotor

There are tons of places in pfSense where the code won't work as expected when doing things like putting various UTF-8 accented chars, or even multibyte characters into passwords, secrets and other settings since it either breaks config.xml or strlen() and other non mb_ prefixed functions don't handle this.

https://redmine.pfsense.org/issues/7186
https://redmine.pfsense.org/issues/7423
https://redmine.pfsense.org/issues/7623

The field in freeradiusclients.xml is not base64-encoded because it wasn't possible with XML and pasword-type field. Now, when you attempt to use some functions to automatically escape/replace things with those non-encoded strings, you run into things like this one. When you switch the field to use base64, you need to write code to upgrade the config automatically on installing the next package version.

Afraid someone else will need to do the job since I frankly think that people that insist on shooting themselves in the foot need to pick up the pieces. (I recall a couple of threads here where people were complaining that putting a carriage return character in password makes their life miserable with password prompts… ::))