Reporting Bugs

Users reporting bugs is a huge part of developing open source software. Reporting bugs is a benefit to everyone involved and ultimately will help create a better product.

That said, reporting false bugs or support requests strains bug marshall and developers time - remember, these people are volunteers, and most have day jobs to earn a living.

Basics: What you did, what should have happened, what did happen

These are the three things we really need to know. Saying "I set up a ring group, and it doesn't work" is not very helpful.

Reporting a bug

Before you report a bug, please be sure it is not a support issue. Getting someone else to try and reproduce it (or doing it yourself on another system) is a great way to confirm it really is a bug, and not something in your setup. See GettingSupport for the many ways to talk to other users.

Search for existing reports first

Always search the bug tracker first to see if your issue has been reported before (or perhaps even already fixed)! Tracking down duplicate bugs is very time consuming, and it's much more useful if you can add more information to an existing ticket.

Don't report bugs about old versions

Be sure you're running the current version. We make this very simple, on the bug report page, if your version isn't listed, then you should upgrade first. The current version can always be found on WikiStart.

Be brief, but concise.

It's a fine line, but try to stick to it the best you can. Remember, what you did, what you expected, and what happened. A log file showing only a call where a problem occurred for example, is useful, but your log file showing 8 calls in progress at the same time is not.

Use English

The community is made up of many groups around the world who speak many languages, but most people are English speaking, and so reporting in another language is a good way to get your problem ignored by most people capable of fixing it who won't understand.

Only report one bug per ticket

If you have two issues that don't appear to be directly related, file two different tickets. This makes it easier to track each issue, and for the appropriate person knowledgeable in that area to help out.

Useful information

Useful information to post is the information you entered to the relevant item, Asterisk CLI output and/or log files.

Asterisk CLI

The Asterisk CLI (command line interface) is the main console to Asterisk itself. You can load it by using a terminal connected to your server, or using a remote shell like SSH to access it. At the prompt, type:

user@host:~# asterisk -rvvvvvvvv

-r means remote, -v means verbose. Alternatively, when connected you can issue the command:

host*CLI> set verbose 8

to increase the verbosity level. This outputs more messages and helps in debugging.

If asterisk doesn't start up, you can usually diagnose this using the -c option, which tells asterisk to run in foreground instead of as a daemon:

user@host:~# asterisk -cvvvvvvvv

When you actually post the output of the bug, be sure to put {{{ on the line before the text, and }}} on the line after. This tells Trac to format it as text, otherwise you'll end up with a garbled mess. See WikiFormatting for help.

Posting log files

Follow the same rules as above for posting output, enclosing in {{{ and }}}.

The logs you post should show only the problem in question, and prefably (if relevant) the complete call taking place.

Following this advice will help the volunteers who maintain freePBX to help you the best. Now that you're ready, go file a new ticket!