Troubleshooting
Two main types of error occur with FusionPBX.
- Error messages in FusionPBX's GUI
- Call behavior doesn't do what you expect.
Additionally you may have problems caused by attackers
- denial of service
Contents
Error messages in FusionPBX's GUI
Fatal error: Call to undefined function recording_js() in /var/www/fusionpbx/www/mod/recordings/v_recordings.php on line 40
- this may be because mod_spidermonkey is not loaded. See the notes on modules
- it also may be because you have upgraded using the upgrade button - note that at the present time the upgrade button is unreliable - it is recommended to upgrade using svn until this is resolved.
Errors when you apply settings
- please see Apply Settings
Error number: 111 error description: connection refused no handle
- usually this means that freeswitch isn't started. If you are using linux try ps -ef |grep freeswitch from the command line to see if it is running.
Error messages at the FreeSWITCH command line
You need to use the FreeSWITCH command line to see the error that is happenning
An essential tool for troubleshooting is the FreeSWITCH command line. See fs_cli for more information. It is probably worth noting that any error displayed at the fs_cli is not technically from FusionPBX, but because FusionPBX works on top of FreeSWITCH, errors seen there may affect functionality. You might want to look in the FreeSWITCH wiki for more information on other errors.
Seen in fs_cli (FreeSWITCH command line interface): SQL ERR [attempt to write a readonly database]
- This relates to a permission problem on your machine. FreeSWITCH is unable to write to its database files located in freeswitch/db. Correct your permissions and restart freeswitch.
Denial of Service
If you are finding that your phones won't register with FreeSWITCH/FusionPBX, maybe the problem is caused by someone attempting to register with your FreeSWITCH box by brute force. This would show up in the fs_cli and in the FreeSWITCH logs. Some earlier versions of FreeSWITCH did not log registration attempts - this was apparently fixed around January 2011 - prior to that some versions had it and some didn't. So it is helpful to have a recent build.
Brute force attacks will usually take FreeSWITCH down fairly quickly - maybe as fast as 15 minutes. Check your logs. Check your firewall logs too. You can also monitor the server using tcpdump (eg. tcpdump -nq -s 0 -A -vvv -i eth0 port 5060) or wireshark (note that the wireshark terminal version is called tshark). If you can see registration attempts flying past you are getting attacked. Another way to see this is using sofia global siptrace on in the fs_cli.
If you are being brute forced one simple fix you can do is to block access to your FreeSWITCH server from outside your firewall. Obviously doing this might impact any external clients you have connecting to it unless they are connecting via VPN. If you can identify a specific address that is attacking you you can block it with your firewall, but that will only help until they change the IP address they are attacking from - still that might be enough to get you out of trouble in the short term.
The Ubuntu build of FusionPBX includes fail2ban which is used to block repeated failed login attempts from an IP address for a period of time. This allows your FreeSWITCH to get on with its job between login attempts rather than having to respond to an endless stream of attempts from the attacker.
There are tool sets such as this one [1] that help you audit the security of VOIP systems.
If you ever need to completely reset fusionpbx to square one
Not really sure when you would want to do this as it is a major thing. If you delete config.php from the fusionpbx/includes directory it will cause FusionPBX to go back to install mode (what happens the first time you run it). If you also delete the sqlite db file from fusionpbx/secure it will clear all your old fusionpbx configuration as well.
