[aprssig] Someone's Server Mangling Packets

Wed Jan 25 08:52:23 EST 2012

q-constructs are a fabrication of the APRS-IS.  They're never 
(supposedly) transmitted over the air and are therefore not subject to 
the vagaries of the AX.25 packet wrapping and encoding.  And the 
required line delimiter is another condition that must be done within 
the APRS-IS transport network, most likely at some originating 
multi-mode client/server, not on the RF side of APRS.

I'm not enough of a math major to be able to work out the requested 
probabilities, but I'd love to see it as well!  If that actually is 
capable of happening, it'd probably result in a less-than-consistent 
modification of the packets, though.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 1/25/2012 8:44 AM, Bob Bruninga wrote:
> Concatenated packets:
>
> I have seen these rarely since the beginning of APRS.  I assumed they were
> my own DOS processor taking a few milliseconds break and as a result
> concatenating packets.  Since the TNC would not make such a mistake due to
> the CRC check, I assumed it was in the  APRS client.
>
> However, if we realize that almost every packet heard these days is a
> concatenation of one weaker packet overlayed with the most recent strongest
> packet, and since the ending flag is the same as a beginning flag, there is
> a finite probability that the sum of a few bit errors could result in a
> concatenated packet with a valid checksum at the end...
>
> I think I theorized this once before, and maybe someone shot it down, but
> I'd like to see the probabiltites again...
>
> Bob, Wb4APR
>
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Lynn W. Deffenbaugh (Mr)
> Sent: Wednesday, January 25, 2012 8:25 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] Someone's Server Mangling Packets
>
> I've been trying to home in the source of these, what I call
> "concatenated" packets for some time now.  There's various kinds of
> corruption, but here's another recent classic example:
>
> 2012-01-25T13:14:35.707 server->client,qAS,sq3fyk-3:
> F1ZZF-2>APNW01,qAR,LX1CU-3:=4922.53N100607.89E#PHG2200 W1 Thionville
> (57) 324m ASL
>
> And another pair of the *'d q-servers:
>
> 2012-01-25T13:17:35.864
> KA0GFC-3>APN391,KA0GFC-2,WIDE2,qAR,KV0S-3*:!3856.83NS09244.74W#PHG9280
> W3,MOn KA0GFC BOONVILLE
> 2012-01-25T13:18:31.216
> KM0R-3>APN391,qAR,KV0S-3*:;IRLP-3121*111111z3859.51NI09222.35W0442.325Mhz
> T127
> KM0R
>
> KV0S-3 itself uses an APN382 identifier
> (http://aprs.fi/?c=raw&call=KV0S-3&limit=50&view=normal) which is
> documented at http://www.aprs.org/aprs11/tocalls.txt as "APN3xx
> Kantronics KPC-3 rom versions"
>
> I'm sure you have your own tools, but if you bring up an APRSIS32
> instance connected to a full feed, just open up Enables / View Logs /
> Concat and enable it.  You'll see various "suspect" packets that I'm
> ignoring and possibly some of my ideas about what I might do with such
> packets in the future.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 1/25/2012 7:23 AM, Pete Loveall AE5PL Lists wrote:
>> I noticed some packets yesterday such as:
>>
>> FWDSVR>APRS,qAO,AE5PL-WX*::NWS_WARN
> :251100z,SVR_STORM,TXC331{PAJAAFWDSVR>APRS,qAO,AE5PL-WX:;FWDSVRAJA*251100z30
> 34.20N\09713.80WT014/035 SVR_STORM }d0]PNPOQNSJSJSJRIRIRIQIQINJMMPN{PAJAA
>> Note the asterisk after AE5PL-WX which is an invalid modification of the
> path (never alter the "last digi'ed" indicator) and the concatenation of the
> object with the message.  Authors, please check your software and ensure you
> are not mangling packets like this.  Server sysops, monitor the output of
> your server to ensure you are not generating these mangled packets (monitor
> the input and output).  We have had an increase of software mangling packets
> like this as well as adding trailing white spaces.  Unfortunately, for the
> volume of packets handled by core servers, there is really no way to
> effectively prevent passage of these mangled packets without blocking some
> valid packets as well.  These are only examples.  I will be issuing an
> update to javAPRSSrvr that blocks any packets with an asterisk following the
> q construct as that is invalid at all times.  I would hope the software
> author of the offending software would correct their software as well since
> it is doing other ma!
> ngling of packets.
>> 73,
>>
>> Pete Loveall AE5PL
>> www.ae5pl.net
>>
>> This electronic message transmission contains information from Peter
> Loveall AE5PL which may be confidential or privileged.  The contents of this
> message are intended solely for the use of the recipient or recipients named
> above.  If you are not the intended recipient, be aware that interception,
> disclosure, duplication, distribution or any other exploitation of this
> message is prohibited.
>> If you have received this electronic transmission in error, please
> immediately notify me by telephone at (972) 838-4107 or by email at
> pete at ae5pl.net
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>