Keyboard Shortcuts
Likes
Search
Third party packets on KISS connections
开云体育I am working on bringing up an APRS bot and I am having some
troubles. Originally I was running Direwolf 1.6 and was having
problems getting packets from the APRS-IS connection to be seen by
the KISS client. This evening I compiled Direwolf 1.7 and used the
ICHANNEL statement. Now I am getting packets from the APRS-IS
connection routed over the KISS connection. That is the good news. The bad news is that the packets are being
received as third party packets and I can not find any references
to how packets should be sent over the KISS connection so that the
reply packet gets routed back over the KISS connection. So on the APRS-IS feed, I am seeing the packet come across as WT0F-4>APDR16,TCPIP*,qAC,T2PRT::APRSFL??
:Test{14 Then on the KISS client, I am seeing the packet come across as X*>X*:}WT0F-4>APDR16,TCPIP*,qAC,T2PRT::APRSFL?? :Test{14 The response that the client sends back (ACK) is (or close it is
as I did not have it handy) APRSFL>APZIOR,WIDE1-1::WT0F-4?? :ACK{14 This packet goes out the RF interface instead of the APRS-IS
connection. So the question is do I need to prepend the packet
with X*>X*:}
or X>X:} ?
Is there any good documentation on how to properly handle third
party packets? Thanks. -- Gerard Hickey / WT?F IRLP:3067/Echolink:529661 hickey@... DMR: 3102272 425-395-4554 Allstar: 531920 MeshPhone: 386-8611 |
|
? The KISS frame uses AX.25 formatting for addresses.? This means the addresses are constrained to maximum 6 upper case letters or digits then an SSID in the range of 0 to 15.??? APRS-IS has looser restrictions.? Lower case can be used, station name can exceed 6 characters, and SSID can be up to 2 alphanumeric characters. Example: AB1OC-10>APWW11,TCPIP*,qAC,T2SPAIN:>FN42er/-DX: WA1PLE-13 43.7mi 154? 02:35 4208.36N 07113.50W<0x20> When something from APRS-IS is conveyed over KISS, we add a fake third party header so the original addresses can be preserved. Example: X>X:}AB1OC-10>APWW11,TCPIP*,qAC,T2SPAIN:>FN42er/-DX: WA1PLE-13 43.7mi 154? 02:35 4208.36N 07113.50W<0x20> Discard the first ":}" and everything before it. Going in the opposite direction, you would need a fake third party header only if any of the addresses violate the AX.25 restrictions.? It might be a good idea to always use it so you don’t need to examine the addresses and have special cases.? Direwolf will simply discard any third party header before forwarding the rest to APRS-IS. More complete details are in "Internal-Packet-Routing.pdf" found in .? I hope this helps. 73, John WB2OSZ |
开云体育It has helped a little bit, but I tried to send a third party
packet back over the KISS connection and I am getting DireWolf
telling me that the packet is not AX.25. I have had? very little
experience with AX.25 at the protocol level so I am probably
missing something pretty basic. Here is what I just got. [ig>tx]
WT0F-4>APDR16,TCPIP*,qAC,T2SPAIN::APRSFL?? :Ping{19 So the initial packet comes in over APRS-IS and my KISS client
sees the packet come in with the third party header on the packet.
At this point I am only attempting to put the third party header
on the ACK. The response from the KISS client (i.e. "Pong!") is
not sent with the third party header hence it is sent out the RF
interface. Any ideas as to why this is not being seen as an AX.25 packet or
what my misunderstanding is? On 1/2/25 11:25 AM, WB2OSZ via
groups.io wrote:
-- Gerard Hickey / WT?F IRLP:3067/Echolink:529661 hickey@... DMR: 3102272 425-395-4554 Allstar: 531920 MeshPhone: 386-8611 |
开云体育I have been doing some reading and experimentation this morning
and have a theory. Hopefully you can confirm my theory. I am using a forked copy of the ioreth script (actually forked
copy running APRSPH) and in this script it converts the AX.25
packet to a byte array and transmits the bytes over the KISS
connection. In the process of converting to the byte array it
shifts all the callsign characters by 1 bit to the left then adds
the SSID to the end of the callsign. The result being the
non-printable characters shown in my last message. Also this morning I found the decode_aprs utility and tried some
experiments with the hope that it would give me more info as to
why the packet was not being seen as an AX.25 packet. What it
seems is that if the KISS connection receives the stream of bytes
it will transmit the over the RF connection with no errors. If the
third party header is added, then Direwolf wants the entire packet
to be the string representation of the AX.25 packet. Does this make sense and could this be what is happening causing
Direwolf to flag the packet as an invalid AX.25 packet? Thanks. On 1/3/25 1:54 AM, Gerard Hickey, WT?F
via groups.io wrote:
-- Gerard Hickey / WT?F IRLP:3067/Echolink:529661 hickey@... DMR: 3102272 425-395-4554 Allstar: 531920 MeshPhone: 386-8611 |
|
On Fri, Jan 3, 2025 at 10:26 AM, Gerard Hickey, WT?F wrote:
X>X:}<0x82><0xa0><0xb4><0x92><0x9e><0xa4>`<0x82><0xa0><0xa4><0xa6><0x8c><0x98>`<0xae><0x92><0x88><0x8a>b@c<0x03><0xf0>:WT0F-4?? :ack19 This part needs to be in plain text, not the AX.25 header format with the characters shifted left.
?
<0x82><0xa0><0xb4><0x92><0x9e><0xa4>`<0x82><0xa0><0xa4><0xa6><0x8c><0x98>`<0xae><0x92><0x88><0x8a>b@c<0x03><0xf0>
?
73,
John WB2OSZ |
开云体育That is what I was suspecting. This evening I had a few mins to
make some changes and send the third party packet in its string
representation. Yet there is still something a little off. [15.is
20250103T20:35:07]
X>X:}WT0F-4>APDR16,TCPIP*,qAC,T2CSNGRAD::APRSFL?? :Ping{29 Curiously, I am sending back the packet with the third party
header, but the packet is being sent out the RF interface instead
of the APRS-IS connection. Direwolf is sending anything that originates from the APRS-IS connection over the KISS connection with the third party header. If I receive a packet without the third party headers, then it was received on the RF interface. Given that it has been pretty consistent on how packets are sent over the KISS connection, I would expect that Direwolf would treat the packets coming back over the KISS connection the same way. If the packet has a third party header then it gets routed to the APRS-IS connection.? At least decode_aprs sees the packets as valid AX.25 packets. pi@wt0f-10:~ $
decode_aprs On 1/3/25 2:02 PM, WB2OSZ via groups.io
wrote:
-- Gerard Hickey / WT?F IRLP:3067/Echolink:529661 hickey@... DMR: 3102272 425-395-4554 Allstar: 531920 MeshPhone: 386-8611 |