RMS Gate Trouble Shooting.Linux RPi

Updated 11 Sept. 2018

Charles S. Schuman, K4GBB
k4gbb1@gmail.com

Automatic Check In (ACI)

The rmsgw_aci utility is located in the/usr/local/bin directory.
It is usually run twice an hour from CRON. However, it does not cause a
connection to the CMS each time. Channel status is communicated every two hours
unless there has been a change in the status of the RMS Gate channel(s).

The same goes for the RMS Gate Version update. The update connection is only made once a day or if there has been a change in the Version.

There are hidden files in ../rmsgw/stat/.version.[call-ssid] and .channels.[name].
Rms_aci reads their file date-time to determine if a connection to the CMS is warranted.

Deleting the .../stat/.* files and running rmsgw_aci will force a updating connection.
The . (dot) files will be restored by rmsgw_aci.

The rmschanstat file

Rmsgw_aci requires the verification of a properly configured and operational AX.25 port.
It does this via a script named rmschanstat, located in /usr/local/bin/.

In the event that you need to modify this script to accommodate your hardware or software, I suggest that you that you rename your replacement file and edit the channels.xml file to point to your customized file. This will keep an update install from replacing it.

For trouble shooting purposes Rmschanstat can be run from the command line.

Rmschanstat requires three variables - type, name & CALL.
Type is usually ax25, name is the port name used to identify the port in the axports file, call is the Gateway's Call sign w/o the ssid. The call MUST be in uppercase.

rmschanstat <type> <name> <CALL>

rmschanstat ax25 0 W4XYZ

Error Messages

"channel {NAME} unavailable"

Check to see that {name} in /etc/rmsgw/channels.xml and the port name in /etc/ax25/axports are the same.

cat /etc/ax25/axports

# Port Callsign Baud PacLen MaxFram Discreptions
0 N4TPO-1 19200 256 5 Radio - 145.030 MHz

less /etc/rmsgw/channels.xml|grep "channel name"

<channel name="0" type="ax25" active="yes">

"port {NAME} unavailable"

Check to see if there is a device attached to port {name} by reading the output of the command.

ps ax | grep attach

7443 ? S 0:00 /usr/local/sbin/kissattach /dev/pts/0 0 44.128.1.19

"interface with {ip} unavailable"

Check to see that there address {ip} for the proc with named port.
Check to see if you have more that one device with the same IP address. Each port should have a unique ip-address

ps ax | grep 44.128.1.19

7443 ? S 0:00 /usr/local/sbin/kissattach /dev/pts/0 0 44.128.1.19

status for interface {INTERFACE[0]} unavailable"

Check the status of the {interface}.
Where type is ax25. Read the output of the command

netstat --ax25

Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
* K4GBB-10 ax0 LISTENING 000/000 0 0

The type should match the type= element of channel named in channels.xml. The type is usually ax25.
The script looks for a entry that matches the call-ssid from channels.xml, the device and that the status is LISTENING. Lack of a LISTENING entry usually indicates that ax25d is not running or the ax25d.conf file does not contain a configuration block for the call-ssid of the RMS Gate.

Note .1 If you have more than one channel defined in channels.xml each channels is checked and the script reports on the status of each channel.

Note .2 Somewhere along the line the distro changes have caused a miss-check of the Interface status.
Line 122 of rmschanstat reads:

   STATUS=($(netstat --protocol=${TYPE} -l | grep "${INTERFACE[0]}" | grep "${CALL}" | grep -i "LISTENING"))

The code is meant to check netstat --ax25 for the gate call, interface (ax0) and the LISTENING status.

The change has caused the grep "${INTERFACE[0]}" element to fail on a valid check.

Edit the line to read:

   STATUS=($(netstat --protocol=${TYPE} -l | grep "${IP}" | grep "${CALL}" | grep -i "LISTENING"))

If that does not work try removing that element:

   STATUS=($(netstat --protocol=${TYPE} -l  | grep "${CALL}" | grep -i "LISTENING"))

RMS Log

The RMS log is usually located in /var/log/rms.There are several levels of logging
(see the RMS Gate Install manual)

The most common Errors are:

Not Authorized

This means that your call has not been coordinated with WL2K or that the coordinator has disabled your access If you have upgraded a previously active station you may not have the authmod in gateway.conf set to SGL.

Incorrect Password

Check the password element of channels.xml.
The password is case sensitive.

CMS Error Codes

This is not a complete list of the networking errors. The most commonly seen is Error = 111.

100 Network is down
101 Network is unreachable
102 Network dropped connection because of reset
103 Software caused connection abort
104 Connection reset by peer
105 No buffer space available
106 Transport endpoint is already connected
107 Transport endpoint is not connected
108 Cannot send after transport endpoint shutdown
109 Too many references: cannot splice
110 Connection timed out
111 Connection refused - The CMS is down/unavailable
112 Host is down
113 No route to host