[aprssig] Weird characters from station VKA

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Heikki Hannikainen
> Sent: Monday, December 01, 2008 10:06 AM

> 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

Actually, JR6VZG improperly put TCPIP*,QAC,JR6VZG-D as his path for transmission over D-STAR.  For general APRS use: TCPIP, TCPXX, and any q construct are -never- to appear on RF.  APRS clients should never append any q construct except qAR (means "Received and gated to APRS-IS by").  APRS-IS servers create all other q constructs for APRS-IS use -only- per the specification at http://www.aprs-is.net/q.aspx 

> 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:

I have seen concatenation occurring with APRS+SA IGates (not sure of the TNC configuration) and I have seen certain versions of aprsD also have issues with null and other non-printable characters due to the use of C string functions instead of memory functions.  I looked for VA7YLW-15 originated packets and only found some gated to APRS-IS by another IGate.  Unfortunately, the destination "call" is APRS so there is no information on the software used.

I saw the same issue with the null character being appended to each AGWTracker transmission.  Something for George to look into.

javAPRSSrvr (primary APRS-IS server software) makes no modifications to "packet" payloads (nulls, etc. are left intact).  It does replace any end-of-line indicator with a cr/lf sequence upon retransmission to ensure a single, proper cr/lf sequence is received at the client per line transmitted.

Hope this helps.

73,

Pete Loveall AE5PL
pete at ae5pl dot net