[aprssig] APRS IS weirdness

[AE5PL Lists]

A simple look at DG1SGE raw packets show:

2/27/2005 21:30
DG1SGE>APU25N,TCPIP*,qAC,DG1SGE:=4816.95N\00944.19E-Hallole ! Standby on
DB0RZ 438,725 {UIV32N} 
2/27/2005 21:30
DG1SGE>APU25N,TCPIP*,qAC,DG1SGE:=4816.95N00944.19E-Hallole ! Standby on
DB0RZ 438,725 {UIV32N} 

Yes, this does appear to be a server problem (unless UI-View is sending
both packets ;-).  Since javAPRSSrvr passes all packets as byte arrays
(does not modify the I field in any manner), this points to other
software which possibly considers the lines as strings.

The offending hub does not have to be inserting both packets, only the
bad packet.  With the convoluted interconnects possible with other
software, an unaltered packet could pass through the network just fine
while this server with multiple upstream connects could be passing the
mangled packet.

Since DG1SGE is connected directly to the APRS-IS, he could tell us
where he is connected and that should start our search.  Note that I am
not implying that DG1SGE is causing the problem: he isn't.  He just
gives us a good starting point in tracing the packets.  javAPRSSrvr
sysops: try setting traceCalls=DG1SGE and let's see if we can see where
this mangled packet is coming from).

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net 

> -----Original Message-----
> From: Steve Dimse
> Posted At: Sunday, February 27, 2005 3:03 PM
> Subject: [aprssig] APRS IS weirdness
> 
> This isn't a findU problem, I can see the same bogus packets 
> on aprsworld, nd grepping the live internet feed yeilded more 
> examples.
> 
> My present guess is somewhere a hub is eating the 
> backslashes, probably a third tier hub in Europe, explaining 
> why this is a central European problem. The trouble with this 
> explanation is the hub must also be injecting a duplicate 
> unaltered packet.