[aprssig] Weird characters from station VKA
Heikki Hannikainen
hessu at hes.iki.fi
Mon Dec 1 11:05:51 EST 2008
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
More information about the aprssig
mailing list