Xastir's server ports

Xastir's default Server Port for communicating with other processes over the network is Port 2023. Xastir listens for both TCP and UDP connections.

Enabling the server ports

The server port is configured using the "Enable Server Ports" option available on the Interface Menu.

This menu option enables and disables TCP and UDP listening sockets at port 2023.

Connecting clients

You may connect other APRS clients to the TCP port in order to send/receive APRS data. The TCP port behaves just like an APRS internet server and feeds data to connected clients in the same format.

Once they authenticate, clients are able to send data to Xastir. Authentication uses the same creditial that is used by APRS internet servers (you can produce this credential with the "callpass" program).

Without authentication, clients are able to receive every bit of TNC and Internet data that Xastir receives but Xastir won't accept any of their data.

Note that ANY user with the proper credentials can come in on the TCP or UDP ports if they are enabled, so if you enable these ports you should be sure your network is secure. The only one of these two ports currently that can send to RF is the UDP Server port. Data coming in from the TCP port cannot be made to go out to RF.

What clients send to the server ports to authenticate

To authenticate, the client must send a string like this one to the server port:

    user WE7U-13 pass XXXX vers XASTIR 1.3.3

Normal APRS clients that understand internet servers

Connect another APRS client to Xastir's server port just as if it were an ordinary APRS internet server and it should authenticate and be able to send to any server that Xastir is connected to, as well as receive packets from all ports/servers Xastir is hooked to.

Injecting data into Xastir's APRS stream

You should also have a binary called xastir_udp_client which can send packets into the UDP listening port. Invoke it like this:

 xastir_udp_client localhost 2023 <callsign> <passcode> "APRS Packet Goes Here"

"APRS Packet" means the whole packet

The "APRS Packet Goes Here" must be a complete APRS packet including FROM and TO callsigns. A common mistake is trying to send only the payload part of the packet, which won't work.

For example, if one wanted to inject an APRS object, one could use

xastir_udp_client localhost 2023 MYCALL-0 <passcode> "MYCALL-0>APX219,WIDE2-1:;foobar   *202111z3501.53N/10619.04W/"

Note that this packet contains a from callsign ("MYCALL-0"), a TOCALL (APX219), a packet path (in this case WIDE2-1), and then the object specification.

Where the injected data goes

Currently that will inject the packet into Xastir's decoding routines and send it to any TCP-connected clients. It will also igate it to the INET if you have igating enabled. It will send the packet out the RF ports as third-party packets only if you add the "-to_rf" flag after the passcode like this:

 xastir_udp_client localhost 2023 <callsign> <passcode> -to_rf "APRS Packet"

The UDP client is useful for generating and injecting APRS packets from external scripts. It can also be used to fetch the callsign of the remote xastir server by using the -identify flag:

 xastir_udp_client localhost 2023 <callsign> <passcode> -identify

When you install Xastir, a man page for xastir_udp_client is also installed. You should be able to run man xastir_udp_client to view it.

Example use cases

You can have one computer with a TNC running Xastir with server ports enabled, then other computers on the same network can connect to Xastir's server port and see the same data. This is useful in operations such as search and rescue base camps or other public event communication centers.
You can write scripts that create APRS objects and inject them into Xastir's database by running xastir_udp_client.
You can write programs that generate information you want to put on the map, and those programs can connect to Xastir's server port and inject that information as APRS objects.