Troubleshooting
This section describes common problems, things to try, and hints to solve the problem.
PTTLink registration fails when behind a NAT router
Some NAT-routers do not honor source-port preservation. Registration (by default) requires that the source port be preserved. The URL register.pttlink.org expects the source port to be 4569 by default. With some NAT routers, source-port preservation is not guaranteed. For example, the Dlink DI series is one such router which does not preserve source port numbers and there is a 100% chance that when the registration packet exits your router, it will use a different (high 60,000 range) port number.
There are two ways to resolve this issue:
1. Send an email to the list requesting your port number be forced to 4569, and one of the
network maintainers will do this for you.
2. Change the router to a brand which is known to preserve source port numbers.
Breaking the keying loop between two simplex nodes
Back and forth keying (aka as "Ping Ponging" or "Relay Racing") can occur when two simplex nodes are linked together. This is caused by COR or squelch noise glitches from certain types of radios. To fix,the COR must be ignored for a small amount of time after a simplex node releases PTT. To accommodate this, edit /etc/asterisk/usbradio.conf and add the following statement in the [usb] stanza or other port-specific stanza:
rxondelay=25
This will instruct the usbradio driver to ignore the COR line for a specified number of 20mSec intervals following the release of PTT.
Cannot Receive Connections or Make Connections to Other PTTNodes
| Hint | Thing(s) to try |
|---|---|
| Is Asterisk Running? | Type asterisk -r at the shell prompt, and see if you can access the Asterisk CLI. If you can access the asterisk CLI, then watch the console output while trying to connect and note what happens. if there is no output, proceed to the next thing to try. If there is output, not what errors or warnings you see on the console and ask a question about them on the mailing list. Please note that the error message: WARNING[5765]: file.c:xxxx waitstream_core: Unexpected control subclass '13' is a expected warning
|
| Connectivity issues? | Try issuing a ping command from the shell to something on your local network. If that works, try pinging google.com.If you get an error that google.com can't be found, check your DNS server settings in /etc/resolv.conf to see if they are correct. If they are incorrect, correct them, save the file, and reboot. If you are running Limey Linux and you change the IP addresses in /etc/resolv.conf, don't forget to run the svcfg command from the shell prompt.
|
| Do you have a current rpt_extnodes file? | Check to see that rpt_extnodes exists in the /var/lib/asterisk directory. Change directories to /var/lib/asterisk: cd /var/lib/asterisk. Type ls and make sure the file rpt_extnodes is listed. If it is not listed, you may have a problem with node registration, an invalid node number or bad password. Check your registration settings in /etc/iax.conf to see if they are correct.
|
| Registration issues? | Does your node number show on a green background on pttlink.org?. If not, your node may not be registering properly to register.pttlink.org. Check the registration statement in /etc/asterisk/iax.conf and make sure the node number and password are correct |
Cannot Receive Incoming Connections From Other PTTLink Nodes
| Hint | Thing(s) to Try |
|---|---|
| Do you have the correct port forwarding settings configured in your firewall? | PTTLink requires that UDP traffic on port 4569 be forwarded from the public (WAN) IP address to the private (LAN) IP address running Limey Linux or ACID. Please check the settings in your router using its instruction manual to make sure port 4569 UDP is set up to be forwarded to the correct internal (private) IP address. If the port forwarding settings are correct in your router, please send a message to the app_rpt-users list requesting help, and we will check to see if your system is properly registering with our registration server. Please include your node number in the message A small number of NAT routers require that we force the port setting to port 4569 on the registration server. This is a manual process and requires intervention from one of the system administrations. |
RTCM Choppy Audio
The RTCM voter protocol is UDP which of course means packets can be dropped causing holes in the audio. Here are a couple of things to look for if the audio is choppy.
Network Problems
The server (chan_voter) sends a keep-alive packet to the RTCM once a second. Likewise, the RTCM sends a keep-alive packet to chan_voter once a second. Timeouts will occur if excessive packets are dropped.
- Start the asterisk console with verbose set to 3 (asterisk -rvvv) and watch for disconnect messages. -- Voter client nameOfClient disconnect (timeout) This means the chan_voter has missed 3 keep-alive packets in a row, or said another way, 3 seconds has passed since the last keep-alive was received.
- If the RTCM off-line fail over message is heard over the air (perhaps quickly followed by the on-line message) the RTCM has missed 6 keep-alive packets in a row. In other words 6 seconds has passed since the last keep-alive was received.
Either of these indicate a network problem that can not be compensated for with RTCM or voter.conf settings. The problem must be fixed using traditional network trouble shooting techniques, ie traceroute and ping. Try running a ping with a count of 100 or more to insure there is no packet loss.
Buffer Size
Voter ping is useful for end-to-end network evaluation when ICMP ping is turned off and/or the RTCM is behind a firewall and is not ICMP reachable. It can help with finding the correct RTCM and voter.conf buffer settings. See Setting Voter Buffers and look at oos (out of sequence) and packet loss. Both should be zero. If not, adjusting the buffer size may reduce oos or packet loss.
URI: TX Audio clipping using composite (tone and voice combined) on same output
Ensure the sum of the SUM of txtone and txvoice should never exceed 1000. If more gain is needed, split the tone and voice outputs. To split the outputs use the follwing configuration in usbradio.conf:
; voice on left channel txmixa=voice ; tone on right channel txmixb=tone
URI: radio tune rxnoise fails
Ensure you have enough audio output from the receiver. Check with a AC voltmeter or scope. You need to have at least 100mV peak of audio for the rxnoise command to complete successfully.
Some radios do not produce enough high frequency noise (above 3kHz) to drive the noise detection DSP. In this case switching to simple usb is recommended.