开云体育

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.

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
[15.is 20250102T22:31:42] X>X:}WT0F-4>APDR16,TCPIP*,qAC,T2SPAIN::APRSFL?? :Ping{19
[0L 20250102T22:31:42] DELAND>APDW17,WIDE1-1:}WT0F-4>APDR16,TCPIP,DELAND*::APRSFL?? :Ping{19
[0L 20250102T22:31:44] (Not AX.25)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
[0L 20250102T22:31:45] APRSFL>APZIOR,WIDE1-1::WT0F-4?? :0103 0131Z:Pong!<0x20>

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:

?

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

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611