[aprssig] APRS-IS and I-gating

[Jim Alles]

I am observing a disconcerting difference in response between the two major
APRS-IS server softwares, aprsc & JavAPRSSrvr.

In preparation for setting up a TX I-gate for the first time in our area, I
started testing my configuration, and getting inconsistent results as I
tweaked, restarted, and got another random APRS-IS server assigned, using
rotate.aprs2.net, as generally recommended.

Although I believe I found a separate issue in the TNC software (I have
posted that conclusion on the direwolf_packet Yahoo! group), this post
focuses on the servers, and I don't have specific recommendations just yet.
I hope that this issue is recognized by someone, before I have to get
through testing for each instance of the server softwares.

The current test bench consists of a single instance of Direwolf, set up
as: Receiver audio => TNC => AGWPE => LAN.
I-gating is disabled there at this time, so no filtering.  This eliminates
any variation of audio levels or hardware for what is heard locally.

The AGWPE port connects to two instances of Xastir, on different machines.
One of these instances is latched on an aprsc server, with my personal
callsign & passcode. The other instance is fixed on a JavAPRSSrvr, with the
Penn State ARC callsign & its passcode. Neither instance has any server
subscriptions/filter entries. This was tested on both machines, after
logging in successfully, and before I-gating packets out, no packets were
logged coming in from the TNC, so no bogus server configs, or default
filters.

Once identical packet streams commence to the two servers, it does not take
long to see that there are many more "dots on the map" - objects, digis,
stations - the density is about double on the JavAPRSSrvr side, where I
believe I should only be seeing what was received over the radio.

Through all of this, I only see one entry in "All Message Traffic", and
that was on the JavAPRSSrvr side. So it appears to me that all of this
extra "stuff" is in response to stations heard by the server.

There is so much extra stuff, from well outside of the receive range, that
it becomes difficult for me to specify a common denominator, for
troubleshooting.

Some of what I see are many packets that have seen the Internet with
"TCPIP*" in the path. There are many objects, which should not be there at
all outside of the RF receive range - even in response to messages. It
looks like there are many stations that show up on the map from the server,
simply because they were repeated by a high-profile digi that was heard by
our very-high-profile digi. There are several clusters of these.

So, without looking at any source code, my guess is it may be that the
wrong field is being matched out of a parsed packet.

I can't say that any of this wants to get transmitted on RF from Xastir.
The log looks reasonable.
However, there can be a significant impact on the local RF environment when
an I-gate like Direwolf seems to want transmit most everything that comes
in from the server.

I would guess that generally, this behaviour would be masked when a
subscription filter is submitted, as you might want most of  these packets
on the map anyway.

Please note that no radio waves have been harmed by this testing, I have no
actual transmitter connected.

Any comments, questions, or suggestions are welcome.

Thanks for your attention to this,

Jim Alles, KB3TBX
Central Pennsylvania
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161104/5a5676d3/attachment.html>