forked from Xastir/Xastir
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxastir_udp_client.1
74 lines (56 loc) · 2.99 KB
/
xastir_udp_client.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
.TH xastir_udp_client 1 2019-05-01 "The Xastir Group"
.SH NAME
xastir_udp_client \- send simple messages to xastir for APRS(tm) network.
.SH SYNOPSIS
.B xastir_udp_client
.I <hostname> <port> <callsign> <passcode> {-identify | [-to_rf] <message>}
.SH DESCRIPTION
xastir_udp_client sends packets into the UDP listening port of an enabled xastir instance.
.SH EXAMPLES
xastir_udp_client localhost 2023 <callsign> <passcode> "APRS Packet Goes Here"
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
.SH NOTES
This is a very simple utility that provides no validation of message
content. The text passed as the last argument is directly injected
into Xastir's incoming data stream and processed exactly as if it had
come out of a TNC.
As such, the text passed to it as "APRS Packet" must be a complete
APRS packet, including FROM and TO call signs, not simply the payload.
Thus to have it work properly, you should pass
"MYCALL-0>APX219:payload goes here" as the string, not "payload goes
here" (where obviously you should replace "MYCALL-0" with your own
callsign and SSID).
If the APRS payload provided is an object or item, and the call sign
and SSID provided in the packet header match Xastir's exactly, then
Xastir will "adopt" the object or item and treat it in the same manner
as one that had been created in its own GUI --- that is, the object
will be retransmitted with decaying intervals until deleted. This can
be useful if one wishes to create objects external to Xastir and have
it take control over them, but can be a bit surprising if you weren't
expecting it. If you want the objects treated as Xastir's own, use
the same callsign and ssid for the object as the callsign/SSID that
Xastir is using, and if you DON'T want that, use a different SSID.
If Xastir's callsign is "MYCALL-0" then this invocation will create an
object that will be adopted and retransmitted:
xastir_udp_client localhost 2023 MYCALL-0 <passcode> "MYCALL-0>APX219,WIDE2-1:;foobar *202111z3501.53N/10619.04W/"
while this invocation will create an object that will only be
transmitted once and not adopted:
xastir_udp_client localhost 2023 MYCALL-0 <passcode> "MYCALL-1>APX219,WIDE2-1:;foobar *202111z3501.53N/10619.04W/"
.SH SEE ALSO
xastir help file
.br
.PP
.B APRS[tm]
is a Trademark of Bob Bruninga, his home page is at "http://www.aprs.org/aprs.html"
.SH COPYING
Copyright (C) 1999,2000 Frank Giannandrea KC2GJS
.br
Copyright (C) 2000-2023 The Xastir Group