<div dir="ltr">On Fri, Nov 4, 2016 at 8:51 PM, Jim Alles <span dir="ltr"><<a href="mailto:kb3tbx@gmail.com" target="_blank">kb3tbx@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div 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. </div></div></blockquote><div><br></div><div>Just for posterity, which specific -IS servers? I know there used to be quite a number of -IS servers which tacked on extra filters on their 14580 ports despite what the client asked for (which is confusing and very annoying), but I thought most of those servers had been fixed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div 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.<br></div></div></blockquote><div><br></div><div>When you connect to a 14580 port with no additional user filters, the server is left to heuristically decide which packets it thinks you might be interested in. To quote <a href="http://aprs-is.net/javAPRSFilter.aspx">http://aprs-is.net/javAPRSFilter.aspx</a> - "So a user-defined filter port (14580) will pass messages and [associated] posits to the client and any gated station (and TCPIP packets from gated stations), and nothing else until a filter definition is added."<br><br>So what you're describing sounds like the expected JavAPRSSrvr behavior. It cc's you on all APRS-IS traffic for all stations which you have recently I-gated, regardless of how far away they are now. Aprsc is more conservative in what heuristics it uses to send you traffic you didn't explicitly ask for. There are arguments for both methods; some prefer to see their maps fill out with more stations, while others prefer the less traffic from aprsc servers. Since the exact behavior is not rigorously defined anywhere, I wouldn't say that either behavior is incorrect, and all clients should be configured to properly handle either.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:georgia,serif"></div><div 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.<br></div><div 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></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">Yeah, no. The premise is wrong here; you definitely don't want to ever have a blanket "RF-gate all traffic from APRS-IS" configuration. APRS-IS servers will send you plenty of traffic to keep your I-gate up to date on stations recently heard via RF, but most of those packets are meant for you, not the entire local RF network.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I-gates should only automatically RF-gate messages and associated posits under something like the following conditions (quoted from the igate.c file from Aprx):</div><div class="gmail_extra"><div class="gmail_extra">*  1. the receiving station has been heard within range within</div><div class="gmail_extra"> *     a predefined time period (range defined as digi hops,</div><div class="gmail_extra"> *     distance, or both).</div><div class="gmail_extra"> *  2. the sending station has not been heard via RF within</div><div class="gmail_extra"> *     a predefined time period (packets gated from the Internet</div><div class="gmail_extra"> *     by other stations are excluded from this test).</div><div class="gmail_extra"> *  3. the sending station does not have TCPXX, NOGATE, or RFONLY</div><div class="gmail_extra"> *     in the header.</div><div class="gmail_extra"> *  4. the receiving station has not been heard via the Internet</div><div class="gmail_extra"> *     within a predefined time period.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">You should be very conservative with what else you configure your I-gate to RF-gate to the local network. Typical RF-gate filter configurations would be for things like "these two repeater objects and any announcements beaconed from that Internet-only APRS station" or "NWS alerts for the city where this I-gate is located"</div><div class="gmail_extra"><br></div><div class="gmail_extra">I haven't been following the thread on the Direwolf list very closely, but if this blanket RF-gate everything behavior is default for Direwolf, that is VERY concerning and arguably incorrect.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF</div><div class="gmail_signature">Aprx Maintainer<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<div class="gmail_quote"><br></div></div></div>