[aprssig] Someone's Server Mangling Packets

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Wed Jan 25 08:24:38 EST 2012


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*251100z3034.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 mangling 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
>






More information about the aprssig mailing list