<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><span style="font-family:arial">On Tue, Dec 3, 2013 at 6:54 AM, Lynn W. Deffenbaugh (Mr) </span><span dir="ltr" style="font-family:arial"><<a href="mailto:ldeffenb@homeside.to" target="_blank">ldeffenb@homeside.to</a>></span><span style="font-family:arial"> wrote:</span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div class="im">
    <br>
    <div>On 12/2/2013 8:17 PM, Lee Bengston
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            </blockquote>
            <div style="font-family:verdana,sans-serif;font-size:small">Yes,
              the heard list should give the IGate the necessary
              packets, but what about the ability of the IGate to
              determine if a station heard on RF is also directly
              connected to the Internet/APRS-IS?  With no range filter
              (or a very small range filter), wouldn't that create the
              possibility of gating a message via RF addressed to a
              station heard on RF that is also connected to the
              Internet?  Or would the IS server take care of this by not
              sending the message to IGates that have gated RF beacons
              from the message recipient - instead only send the message
              to the addressee?</div>
          </div>
        </div>
      </div>
    </blockquote>
    </div>The APRS-IS server(s) not only send messages addressed to the heard
    list stations, but also any posits for those heard stations as
    well.  This allows the IGate to determine #4 in (from
    <a href="http://www.aprs-is.net/IGateDetails.aspx" target="_blank">http://www.aprs-is.net/IGateDetails.aspx</a>, emphasis mine):<br>
    <br>
    <blockquote type="cite"><div class="im">
      <p> Gate message packets and associated posits to RF if all of the
        following are true: </p>
      </div><ol>
        <li>the receiving station has been heard within range within a
          predefined time period (range defined as digi hops, distance,
          or both). </li><div class="im">
        <li>the sending station has not been heard via RF within a
          predefined time period (packets gated from the Internet by
          other stations are excluded from this test). </li>
        </div><div class="im"><li>the sending station does not have TCPXX, NOGATE, or RFONLY
          in the header. </li>
        </div><div class="im"><li>the receiving station has<b> not </b>been heard via the
          Internet within a predefined time period.<br>
          A station is said to be heard via the Internet if <b>packets
            from the station contain TCPIP* or TCPXX* in the header</b>
          or if gated (3rd-party) packets are seen on RF gated by the
          station and containing TCPIP or TCPXX in the 3rd-party header
          (in other words, the station is seen on RF as being an IGate).</li></div></ol></blockquote></div></blockquote><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Yep, I was aware of the rules above - just thought momentarily that the IGate would have to gather the information to make the decision for #4 via a range filter.  I remember now that the server actually sends those posits.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    To provide for the determination of #4, my understanding (and
    observation) is that the APRS-IS servers forward any packets sourced
    by the heard stations to the IGate client on the filter port.  This
    is why IGates with no filters will STILL receive packets from the
    APRS-IS that are NOT intended to be transmitted to RF, but provide
    visibility for the IGate to make local gating decisions.<br></div></blockquote><div> </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Which makes sense in the context that non-mapping software such as APRX says in the manual to not specify a range filter (at least it did the last time I looked, which was quite a while ago).</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    There's (at least) one IGate implementation out there (don't
    remember which one) that blindly transmits 3rd party packets via RF
    for every packet received from the APRS-IS server.  In my
    understanding, this is not proper as the APRS-IS servers forward
    information-providing packets not intended for transmission, but
    instead rely on local IGate intelligence to determine which packets
    should actually be gated from -IS to RF.</div></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">And that is what triggered my memory - my own experience with IGate software that did exactly what you described!  I know of at least 3 IGate software apps that either behave as described above or did behave that way at one time before they were updated.  I don't think the authors understood that the server would send more than just messages and posits associated with the message origination, so they just gated everything assuming no harm would be done as long as no range filter was specified.  One application I recall had an easy fix - put an outbound filter on the RF side of messages only.  Of course that meant no "courtesy posit" with a message, but not supporting courtesy posits is a minor thing in my mind.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I don't know if there is a documentation gap or not, but it seems that what is not so well understood by "the community" is how the IS servers recognize IGates and what is sent to them when no filter is specified by the IGate.  I think it is a lot better understood now - at least by the readers of this list.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Thanks,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
Lee - K5DAT</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"></div></div></div></div>