<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">I am observing a disconcerting difference in response between the two major APRS-IS server softwares, aprsc & JavAPRSSrvr.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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 <a href="http://rotate.aprs2.net">rotate.aprs2.net</a>, as generally recommended.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">The current test bench consists of a single instance of Direwolf, set up as: Receiver audio => TNC => AGWPE => LAN. </div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">I can't say that any of this wants to get transmitted on RF from Xastir. The log looks reasonable.</div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Please note that no radio waves have been harmed by this testing, I have no actual transmitter connected.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Any comments, questions, or suggestions are welcome.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Thanks for your attention to this,</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Jim Alles, KB3TBX</div><div class="gmail_default" style="font-family:georgia,serif">Central Pennsylvania</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div></div>