<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">Sorry for the duplicate post, this is what I intended to send:</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Replies in-line. And please take this as a philosophical rant, not personally ;-)</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 5, 2016 at 1:51 AM, Kenneth Finnegan <span dir="ltr"><<a href="mailto:kennethfinnegan2007@gmail.com" target="_blank">kennethfinnegan2007@gmail.com</a><wbr>></span> wrote:<br><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"><span class="m_336877610572874435gmail-"><div><br></div></span><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" target="_blank">http://aprs-is.net/javAPRSFilt<wbr>er.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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif">​Agreed, and I fully understand that the spec is open to interpretation. To me. a single courtesy position packet from a station AFTER I have just I-gated a message from (-the 'association' mentioned) to my local RF is sufficient, and helpful to the person receiving the message, to figure out who it came from, and where they are, regardless of my normal scope of operations as an I-gate operator.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Especially when this messaging thingy can be broken by two stations using the same tactical calls, from opposite coasts of the continent.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">The issue I have is that I am seeing third-party traffic (and objects - these are supposed to be station positions) from digis I have heard once or twice, from over 350 miles away, and *no message traffic logged*. </div></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">And, no I cannot configure my station to not show that extra stuff on the map... with just any client. (I'll expand on that in another thread).</div><div class="gmail_default" style="font-family:georgia,serif">But the I-gate is supposed to be be making the heuristic decisions based on the specific "TCPIP"-containing  packets. And I think that is the primary purpose of this extra traffic, just on the basis of the 'heard hash table' of my station.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">And if it is simply up to preference, then I of course I can choose which APRS-IS server to use. but not while using <a href="http://rotate.aprs2.net" target="_blank">rotate.aprs2.net</a>; which is recommended, and normally good operating practice.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">And I hesitate to say that, because in this case, I do NOT want to see aprsc map bug-for-bug for the sake of consistency - again, the opinion is mine.</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"><span class="m_336877610572874435gmail-"><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></span><div class="gmail_extra">Yeah, no. The premise is wrong here; you definitely don't want to ever have a blanket <div class="gmail_default" style="font-family:georgia,serif;display:inline">​​</div>"RF-gate all traffic from APRS-IS" configuration.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif">​I am  not sure what premise, but I am talking about a garden hose vs. the slow drip I would expect - not the fire hose ​of <div class="gmail_default" style="display:inline">​</div><span style="font-family:arial,sans-serif">"RF-gate all traffic from APRS-IS" at all,</span></div><br></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 class="gmail_extra"> 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></blockquote><div><div class="gmail_default" style="font-family:georgia,serif">​Agreed - though not meant for me & my map so much, as my I-gate softwares consumption. That is why, as a novice I-gate operator I assumed 'I hadn't seen the light'​ vs. the awful realization that I have stumbled on the need to trouble-shoot two entirely different issues, at the same time, AND they interact with each other.</div></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 class="gmail_extra"></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"<br></div></div></blockquote><div> </div><div><div class="gmail_default" style="font-family:georgia,serif">​Agreed 100%, however, there is one other point of confusion I have uncovered.​ In most client software I have used, I cannot minimize traffic any further than leaving the subscription/filter field blank, which is the case for this test scenario. In my opinion, that is not enough, but again, I'll save that for a separate thread.</div></div><div> <br></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 class="gmail_extra"></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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif">​Be careful, my first thread there was just me working through my confusion as a new user of THAT client (when I am talking to myself, it is not likely to be very coherent ;-)​</div><br></div><div><div class="gmail_default" style="font-family:georgia,serif">​Also, the test bench configuration described there is entirely different than the one used for the purpose of this thread - do not be confused!​</div><br></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 class="gmail_extra"><div><div class="m_336877610572874435gmail-m_-6722455938127878129gmail_signature">--<br>Kenneth Finnegan, W6KWF</div><div class="m_336877610572874435gmail-m_-6722455938127878129gmail_signature"><br></div></div></div></div></blockquote><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">​Thanks for your attention to this!</div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">Jim A.​</div> </div></div><br></div></div>