[aprssig] Weird characters from station VKA

[Heikki Hannikainen]

   Hi,

On Sun, 30 Nov 2008, Scott Miller wrote:

> While monitoring a station in Canada on the APRS-IS stream to help a
> user debug a problem there, I saw a packet come through with a report
> from VKA in Australia that had one of the Canadian packets tacked onto
> the end.
>
> Checking on findu, I see that there's a non-printable character at the
> end of every packet from VKA.  Presumably something out there is getting
> confused by this.  Findu itself doesn't show the concatenated packets,
> but it's there on the APRS-IS.  Perhaps it's a null character and findu
> thinks it's the end of the string, while the IS servers get confused and
> pass it along with the next line?

   Yup, it's a null (before the CRLF): http://aprs.fi/?c=raw&call=VKA

   I have seen two APRS packets on the APRS-IS without a CRLF between them. 
Several times. Didn't make any statistics or additional investigation. But 
I wouldn't guess that it's related to the null bytes.

   There are plenty of stations sending packets with lots of null bytes, 
mostly with a destination callsign of APAGW (agwtracker with UTF-16 
unicode messaging enabled). They normally put a null byte as every second 
character if the transmitted text would otherwise be plain ASCII:

   http://aprs.fi/?c=raw&call=JS6QUG

This would be avoided by using UTF-8 unicode encoding instead of UTF-16. 
It'd be backwards compatible with ASCII when only ASCII characters are 
written.

I think there's a bug in agwtracker, it seems to send packets with an 
appended null byte even when unicode messaging is disabled:

http://aprs.fi/?c=raw&call=JF4SJT-12
http://aprs.fi/?c=raw&call=KC0OFZ-2
http://aprs.fi/?c=raw&call=N4BSA
http://aprs.fi/?c=raw&call=VE9SC

Those popped up on the top of the list when I queried my database for 
null bytes. There were 80 stations sending them within the past 60 
minutes.

But these are so common, that I would be surprised if the null byte 
triggered the two-packets-with-no-crlf issue. When looking at packets with 
null bytes in the end, there are usually no packet concatenation problems 
around there.

Now, if I do a query for "%,qA%,qA%" (% is the "match all" SQL wildcard 
character, like * in normal glob matching), the top 5 list (within past 5 
hours) with concatenated packets is:

  JR6VZG-I  16
  VE7ROW    6
  VE7EHP-9  4
  VE7MMG-1  2
  VE7CHW    2

JR6VZG-I (or JR6VZG-D?) is a buggy APRS-IS client sending ,QAC, instead of 
,qAC, and getting another Q construct. The next four are all using 
VA7YLW-15 as their igate. I wonder if there's something fishy going on in 
there (at the igate or at it's upstream server). The packets look like 
this:

VE7CHW>APU25N,SUNPKS,VE7ROW,WIDE1*,qAS,VA7YLW-15:=50VE7ROW>APN391/1,qAR,VA7YLW-15:!4953.88NS11943.88W#PHG3834/W3,SSn 
Crystal Mountain APRS [Invalid uncompressed location]
VE7ROW>BEACON,qAS,VA7YLW-15:T#859,14aprsdYLW>APD225,TCPIP*,qAI,aprsdYLW:=4947.75N\11930.14W&OCARC 
Igate [Invalid telemetry packet]
VE7ROW>BEACON,qAS,VA7YLW-15:T#865,143,147,12aprsdTUX>APD225,TCPIP*,qAI,aprsdTUX,VE7ROM-15,aprsdYLW:=4954.40N\11923.50W&Kelowna 
Igate [Invalid telemetry packet]
VE7EHP-9>APOT02,VE7RKA,VA7YLW-1*,WIDE2-1,qAS,VA7YLW-15:/011356z/4mxZ0#LMk`LG/A=002088 
monitoring 146.500 mhz, ve7ehp at racVE7RPC>BEACON/1,qAR,VA7YLW-15:Campbell 
Mtn APRS Digi VE7RPC [Rate limited (< 5 sec)]

(The query will also return plenty of mic-e packets with a ,qA in the 
encoded payload, but that's OK.)

   - Hessu, OH7LZB