adam/LoRa_APRS_iGate
1
0 Fork 0
mirror of https://github.com/richonguzman/LoRa_APRS_iGate.git synced 2026-10-31 02:51:58 +01:00
Code Issues 55 Packages Projects Releases Wiki Activity

Invalid TX packet #160

New Issue
Closed
opened 2026-10-05 05:43:48 +02:00 by adam · 6 comments
adam commented 2026-10-05 05:43:48 +02:00
Owner
Copy link
Copy source

I see lots of messages like this:

<165>1 - IW2OGY-10 CA2RXU_LoRa_iGate_1.3 - - - TX / IW2OGY-10>APLRG1,WIDE1-1:}IW2NBW>APRS,TCPIP,IW2OGY-10*:;EL-IW2NBW*111111z4528.08NE00849.83E0144.638MHz T071 R16k SvxLink BOFFALORA TICINO

That packet is invalid because the } in this part WIDE1-1:}IW2NBW is errornous. I don't know if that's a logging bug or if that's what it actually tries to TX. Removing the } makes it a valid packet.

I see lots of messages like this: ```<165>1 - IW2OGY-10 CA2RXU_LoRa_iGate_1.3 - - - TX / IW2OGY-10>APLRG1,WIDE1-1:}IW2NBW>APRS,TCPIP,IW2OGY-10*:;EL-IW2NBW*111111z4528.08NE00849.83E0144.638MHz T071 R16k SvxLink BOFFALORA TICINO``` That packet is invalid because the `}` in this part `WIDE1-1:}IW2NBW` is errornous. I don't know if that's a logging bug or if that's what it actually tries to TX. Removing the `}` makes it a valid packet. <!-- github-sync-id:2765254057 -->
adam closed this issue 2026-10-05 05:43:48 +02:00
adam commented 2026-10-05 05:43:49 +02:00
Author
Owner
Copy link
Copy source

This is Third party packet

When a packets comes from aprs servers

This is Third party packet When a packets comes from aprs servers <!-- github-comment-id:2567143173 -->
adam commented 2026-10-05 05:43:50 +02:00
Author
Owner
Copy link
Copy source

I wonder how it could make it through given it's not parseable, or at least the library I'm using can't. I'm fairly confident the } is being inserted by "something" incorrectly, just no idea where or how it could come from APRS-IS in that bad state

currently seeing around 1500 of them per hour, they end up in 'failed message' table just now

I could programatically remove the } and parse it but that feels wrong!

I wonder how it could make it through given it's not parseable, or at least the library I'm using can't. I'm fairly confident the `}` is being inserted by "something" incorrectly, just no idea where or how it could come from APRS-IS in that bad state currently seeing around 1500 of them per hour, they end up in 'failed message' table just now I could programatically remove the `}` and parse it but that feels wrong! <!-- github-comment-id:2567143824 -->
adam commented 2026-10-05 05:43:50 +02:00
Author
Owner
Copy link
Copy source

madspy -

The } data type indicator represents a third party packet. When a packet is forwarded, from APRS-IS, to RF, the packet is encapsulated within a third party packet. You might find it useful to read "Understanding APRS Packets" in https://github.com/wb2osz/aprsspec .

More details are in Chapter 17, of the APRS protocol spec 1.2, Don't use APRS101.pdf. It is obsolete.

The processing of this type of packet depends on the type of station that receives it.

(1) A digipeater only looks at the first via path (before the “}“) and doesn’t need to have any knowledge of third party packets.

(2) An application that wants to interpret the information part of the packet must first remove the encapsulation and process what is left over.

(3) An RF-to-IS IGate first removes the encapsulation and operates on the rest. If the remaining via path contains TCPIP, the packet must not be forwarded. This prevents loops.

Don't hesitate to contact me directly if you have any questions.

73,
John WB2OSZ
arrl.net

madspy - The } data type indicator represents a third party packet. When a packet is forwarded, from APRS-IS, to RF, the packet is encapsulated within a third party packet. You might find it useful to read "Understanding APRS Packets" in https://github.com/wb2osz/aprsspec . More details are in Chapter 17, of the APRS protocol spec **1.2**, Don't use APRS101.pdf. It is obsolete. The processing of this type of packet depends on the type of station that receives it. (1) A digipeater only looks at the first via path (before the “}“) and doesn’t need to have any knowledge of third party packets. (2) An application that wants to interpret the information part of the packet must first remove the encapsulation and process what is left over. (3) An RF-to-IS IGate first removes the encapsulation and operates on the rest. If the remaining via path contains TCPIP, the packet must not be forwarded. This prevents loops. Don't hesitate to contact me directly if you have any questions. 73, John WB2OSZ <callsign><at>arrl.net <!-- github-comment-id:2567211440 -->
adam commented 2026-10-05 05:43:51 +02:00
Author
Owner
Copy link
Copy source

@wb2osz Thank you very much for the explanation and pointers (also, great references you have in your repo!).

The issue appears to be that aprslib (any version) does not know how to parse these types of packets. By admission of the author the decode function is incomplete so this is simply and example of that.

I don't really need to parse these particular packet types so for now I'll skip them, though maybe tempted to patch the library in the future.

@wb2osz Thank you very much for the explanation and pointers (also, great references you have in your repo!). The issue appears to be that aprslib (any version) does not know how to parse these types of packets. By admission of the author the decode function is incomplete so this is simply and example of that. I don't really need to parse these particular packet types so for now I'll skip them, though maybe tempted to patch the library in the future. <!-- github-comment-id:2567380541 -->
adam commented 2026-10-05 05:43:52 +02:00
Author
Owner
Copy link
Copy source

@wb2osz Thank you very much for the explanation and pointers (also, great references you have in your repo!).

The issue appears to be that aprslib (any version) does not know how to parse these types of packets. By admission of the author the decode function is incomplete so this is simply and example of that.

I don't really need to parse these particular packet types so for now I'll skip them, though maybe tempted to patch the library in the future.

maybe you can use the un-encapsulated third-party packet for decoding.

this packets are coming from APRS-IS/Internet and Tx over RF , so the first part shows where it gets Tx and by whom.... but the real "original" packet is after this.

> @wb2osz Thank you very much for the explanation and pointers (also, great references you have in your repo!). > > The issue appears to be that aprslib (any version) does not know how to parse these types of packets. By admission of the author the decode function is incomplete so this is simply and example of that. > > I don't really need to parse these particular packet types so for now I'll skip them, though maybe tempted to patch the library in the future. maybe you can use the un-encapsulated third-party packet for decoding. this packets are coming from APRS-IS/Internet and Tx over RF , so the first part shows where it gets Tx and by whom.... but the real "original" packet is after this. <!-- github-comment-id:2567681834 -->
adam commented 2026-10-05 05:43:53 +02:00
Author
Owner
Copy link
Copy source

closing this as its been explained :)

closing this as its been explained :) <!-- github-comment-id:2567946618 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/LoRa_APRS_iGate#160