[aprssig] Does anybody know what APZMVA is?

Mon Nov 9 18:48:55 EST 2015

In keeping with the goal of APRS, real-time tactical situational awareness,
these traffic incidents are much better for the mobile operator if they are
on RF.  But of course, transmitted ony via 1 hop to the local digi closest
to the situation.

Hope you can figure out a way to do that and manage it to avoid abuse by
people flooding their local area.

On a second note, any TOCALL  not beginning with "AP" will possibly be
ignored by many clients since "AP..." is the flag that tells APRS clients
that the packet is an APRS packet.

Bob, Wb4aPR
-----Original Message-----
From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Frank Knobbe
via aprssig
Sent: Monday, November 09, 2015 4:19 PM
To: aprssig at tapr.org
Subject: Re: [aprssig] Does anybody know what APZMVA is?

On 11/7/2015 4:17 PM, Andrew P. via aprssig wrote:
> 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<
K4FHK-15>/yn8U#*n
> __I-65-N DEBRIS, LEFT LNS BLOCKED

Greetings,

I'm the developer of the TNMVA project. I double-checked the code and also
monitored network traffic to the APRS-IS server, and I am not seeing this
issue. I monitored the network sessions with ngrep.
66.179.102.190 is my server running the TNMVA and other APRS applications.
The packets are sent to APRS-IS like so:

T 2015/11/09 13:52:53.464157 66.179.102.190:1379 -> 52.0.40.3:14580
(iad2.aprs2.net)

user K4FHK-IS pass ***** vers TN-MotorVehicleAccidents V0.6 filter m/1
K4FHK-IS>APZMVA,TCPIP*:!3559.03NT08623.99W&Originator of TNMVA objects.
K4FHK-IS>Send comments to tnmva at knobbe.us APZMVA,TCPIP*:>Seeking Gaters
K4FHK-IS>to RF in Mem/Jax/Chat/Knox/JC. Please email me
K4FHK-15>APZMVA,TCPIP*:;TNMVA64c7*091633zI<c&V9#/0n __I-75-N INCIDENT,
ON-RAMP BLOCKED.

I also have another application running that is tapped into APRS-IS as well,
with a different connection. On that connection, I observed the same object
placement as it was propagated and received through APRS-IS, and it appears
to arrive properly:

T 2015/11/09 13:52:53.800449 144.202.128.17:14580 (bwi.aprs2.net) ->
66.179.102.190:3886

K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:!3559.03NT08623.99W&Originator of
K4FHK-IS>TNMVA objects. Send comments to tnmva at knobbe.us
K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:>Seeking Gaters to RF in
K4FHK-IS>Mem/Jax/Chat/Knox/JC. Please email me
K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64c7*091633zI<c&V9#/0n
K4FHK-15>__I-75-N INCIDENT, ON-RAMP BLOCKED

K4FHK-IS is the application/server that is injecting objects into APRS-IS.
The objects themselves are injected either with callsign
K4FHK-15 or K4FHK-51.

Note that K4FHK-51 is intended to be APRS-IS only. K4FHK-15 may be picked up
by Igates and brought onto RF. Currently, the only Igate doing so is my own,
and if any such objects are gated back from RF to IS, they would be coming
from callsign K4FHK-3. So your observation of the issue with callsign
K4FHK-15 related to packets are only present on the APRS-IS side, and were
not gated from RF to APRS.

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

I'm not sure that this is a timing issue. While the status and object of
K4FHK-IS are sent out rapidly, followed by any objects from K4FHK-51, any
interspersed object from K4FHK-15 would incur a pause due to the server
controlled throttling of these objects intended for RF.

If multiple IS-only packets can not be sent in succession, I can certainly
add a sleep time of a second or two between these, but given the low amount
of successive packets, I didn't think that would be necessary. I think there
are other applications out there (Metar/weather, Winlink, etc) that also
send large batches onto IS without wait times between packets.

BTW: I just joined this list today, since your mentioning of my call sign
and MVA application was forwarded to me by a fellow Ham (Thanks Andrew!). I
can write up a short introduction of myself and the TNMVA service and post
it to this list shortly, if this is proper etiquette and desired on this
list.

There is also another application I developed and would like to introduce to
the community as well. For that application, I would like to "apply" for an
APRS-IS callsign, so I would like to seek your input on the application
itself, and the proper process of acquiring and using a tactical, IS-only
callsign.

Best regards,
Frank Knobbe, K4FHK

_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig