[aprssig] Maximum APRS Packet Lengths and 3rd party use?

Scott scott23192 at gmail.com
Wed Nov 30 15:02:32 EST 2016


As a novice, could I trouble the group for the correct filter syntax to 
block *TCPIP* from being iGated?

And while we're at it, if there are any other filters that should "always" 
be included in any iGate setup, those would of course be welcome as well.

Many thanks!

-Scott,  K4KDR
Montpelier, VA  USA



--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

-----Original Message----- 
From: Robert Bruninga
Sent: Wednesday, November 30, 2016 2:54 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Maximum APRS Packet Lengths and 3rd party use?

All,

Pete confirms that 3rd-party ON-AIR formats are OK with the APRS-IS as long
as IGates do it the right way...  That is:

"IGates should not gate 3rd party packets *that*contain*TCPIP* in the 3rd
party header back to APRS-IS ... since by definition (TCPIP in them) those
packets originated from APRS-IS already.

The problem is that some authors "blocked all 3rd party packets as a "quick
fix" without also parsing to see if TCPIP was included.

So, since no one can guarantee what is implemented in all the possible IGate
code, people are advised that the use of a 3rd party format on RF may or may
not work in all IGates.  Though, we should find, and clearly identify  or
weed out, those IGates that do not check for the TCPIP key word.

Thanks, Pete...

Bob, WB4APR

-----Original Message-----
From: Robert Bruninga [mailto:bruninga at usna.edu]
Sent: Wednesday, November 30, 2016 12:07 PM
To: TAPR APRS Mailing List
Cc: pete at ae5pl.net; Steve Dimse; Robert Bruninga
Subject: RE: [aprssig] Maximum APRS Packet Lengths and 3rd party use?

➢ #1) I vote for the shorter, cleaner, human readable, third party format
FWIW.

I’m going to ask Pete Loveall or Steve Dimse to remind me once again, if
general Purpose THIRD PARTY format can be used on the air and will get into
or through the APRS-IS without conflicting with the APRS-IS use of 3rd party
as a loop filter.  I believe this restriction on general purpose use of 3rd
party went away when the QAR and TCPIP constructs were implemented.?

> it as being 80-columns?)!

To clarify, 80 columns has nothing to do directly with any specific APRS
format directly.  But someone asked why all the packet formats have limits.
And the answer is derived from the original display width of the IBM PC AT
of 80 chars.

>From that 80 column width, the actual APRS format limits vary significantly
so that the actual displayed data as parsed was within that limit.

So to translate, you have to adhere to the SPEC limits for each format
individually.

And the limits are there so that anyone who transmits beyond those lengths
has been made aware that almost all other APRS stations will not receive or
display data beyond those limits.  Doing otherwise would obsolete tens of
thousands of users with Kenwood and Yaesu, and all other kinds of hardware
APRS systems.

I wonder if anyone has done a recent DUMP of all station types on the air?
Hummh...

Bob, WB4APR
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig 




More information about the aprssig mailing list