[aprssig] Does anybody know what APZMVA is?

[Andrew P.]

Greetings.

I've noticed an unusual new experimental tocall value APZMVA, that seems to be associated with some oddly formatted APRS-IS messages. I was just curious what that might be.

Regarding the unusual formatting (which probably has nothing to do with the APZMVA program, as I am seeing from other tocalls as well), I am seeing packets from the APRS-IS that look like this:

K4FHK-15>APZMVA:K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64a2_072105zI</yn8U#*n __I-65-N DEBRIS, LEFT LNS BLOCKED

Note that the sender>tocall section is repeated twice, with a colon (':') delimiting the two occurrences. I'm wondering if this might be an issue with some dialects of the APRS-IS server code (specifically aprsc, since it is the one that shows up for every I-gate I've back-tracked), should my application not be reading the TCP socket connection fast enough, that the server might get the first part of a message stuffed in the stream, and then discards the rest of the message because of a TCP window overflow. That would make this appear like two concatenated messages with most of the first message gone, including the CRLF delimiter between the two messages. I've got a 48Kb TCP window size configured in my application, so there should be plenty of kernel-level buffering to allow for any pauses at the application level.

The occurrence doesn't seem to be a function of the incoming message rate.

Anybody have any ideas what's going on? Or is this a new format of I-gated messages from some I-gates? Note that some of the offending I-gates are UIView, so it can't be anything new (because other UIView I-gates aren't doing this).

Any suggestions would be welcome.

Andrew Pavlin, KA2DDO
author of YAAC ("Yet Another APRS Client")
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20151107/6b22f1c7/attachment.html>