Posting questions to the User's mailing list

Many people ask questions on the FreeRADIUS users mailing list.
Good questions get good answers. Bad questions or those lacking
information just waste the time of the people who are trying to
help.

The most important things are to clearly state your problem
(not the problem with your solution) and to include full debug
output from the server.

It is hard to help you when the post is only a vague question,
and no debug output is included.

Your post should include the following information:

What you are trying to do

why you are trying to do it

what you expect the server to do

what the server does instead (i.e. debug output).

When you give this information, it means that we can help you quickly and efficiently. When you don't give this information, the usual response to your post will be a request for this information. You can get answers more quickly by starting off with good questions.

Full server debug output

This is really important. The server produces comprehensive
information on what it is doing, for a reason. In 99% of the situations, the debug output contains the information needed to solve the problem.

We understand that the debug output is complex and full of what seems like magical text. You don't need to understand all of it. But the people on the mailing list do understand it, and can use it to help you.

When you post the debug output, the whole debug
output needs to be included.

Run radiusd -X only (freeradius -X on Debian based
systems). Don't run -xx or -Xxx or any other combinations,
unless you are specifically asked to. Timestamps and other debug
output just clutter up the e-mail and make it hard for people to
help.

Capture right from the starting banner, not just the few lines
you think are useful.

Include a packet being processed. If you post the debug output
which doesn't show any packets being received, nobody can tell what
happens when the server receives packets.

Don't post the debug output where the last line is Ready to process requests. This means that the server hasn't received any packets. If you post that, the only thing that will happen is that people will ask you to post the debug output, again, but this time where it receives packets.

Include the right packet, in other words, include the one with
the problem. If you've got some authentication that works, and
another that doesn't, then include an authentication attempt for
both.

Things to avoid

While there are recommendations for what you should do, there are also recommendations for things you shouldn't do.

Don't include unimportant packets If you have a problem with Access-Request packets, don't post a debug output which contains Accounting-Request packets, or packets for users who authenticate successfully.

Don't send configuration files to the list. All of the information we need is in the debug output. Which is why we ask for the debug output.

Don't post screen captures of a terminal window which contains the debug output. Honestly, we shouldn't even have to say this. It's not hard to cut & paste text from a terminal window into a mail message.

Don't post the same message multiple times. Everyone got your first message. There's no reason to send it again. If no one responded to your message, it's likely because the message is missing critical information. See above.

Don't complain about any help you receive. The people replying are trying to help you, even if you don't understand their replies. Ask more questions. Ask for clarification. Do the things they tell you to do. Complaining about their free help is not a good idea. It's the number one way to get banned from the list.

Getting debug output

The most basic method of getting the required debug output is to
start the server as follows:

radiusd -X 2>&1 | tee debugfile

wait until the server says

Ready to process requests

then perform an authentication. Once this has taken place, press
Ctrl-C to stop the server, and include the contents of the
debugfile file in your e-mail, in its entirety. The list is used
to long debug outputs, don't worry about it being too big.

Please post the debug output in-line in the email. Do not add it as an attachment. The more steps people have to take to read your message, the less likely it is that they will help you.

Please do not post PNG screen captures of a terminal window showing the debug output.

A good debug output will look something like the following, which is explained here