<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Oh, and an e-mail to KC0WIF to ask about his configuration,
    specifically what is connected to RF and whether or not KC0WIF-1 is
    a local server would confirm or deny my theory.<br>
    <br>
    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
    <br>
    On 5/16/2012 4:50 PM, Lynn W. Deffenbaugh (Mr) wrote:
    <blockquote cite="mid:4FB412F8.6010603@homeside.to" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      If I had to guess, N0NPO-1 was received by a station that is
      connected to the UI-View instance KC0WIF-1 as an upstream server. 
      Whatever did the receiving probably didn't put the qAR in the
      packet, and UI-View (guessing here) doesn't do any q-Construct
      mucking but simply forwarded the packet to the APRS-IS server
      upstream from there (probably a javAPRSSrvr instance somewhere). 
      When the packet got there, it wasn't from the logged on station,
      and didn't have a q-Construct, so it got flagged as qAS using the
      logged on server's callsign-SSID per the following processing rule
      from <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.aprs-is.net/qalgorithm.aspx">http://www.aprs-is.net/qalgorithm.aspx</a>
      (an invaluable reference, BTW, if you can grok it):<br>
      <br>
      <blockquote type="cite">
        <pre>All packets from an inbound connection that would normally be passed per current validation algorithm:
{
.... Non-applicable code removed....
</pre>
      </blockquote>
      <blockquote type="cite">
        <pre>    If a q construct exists in the header:
        Skip to "All packets with q constructs"
.... Not this one so....
</pre>
      </blockquote>
      <blockquote type="cite">
        <pre>    If header is terminated with ,I:
    {... Nope...
    }
    Else If the FROMCALL matches the login:
    {... Nope...
    }
    Else
        Append ,qAS,login
.... I suspect it's this that did it...
</pre>
      </blockquote>
      <br>
      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
      Win32<br>
      <br>
      On 5/16/2012 3:53 PM, John Gorkos wrote:
      <blockquote
cite="mid:CAJcxM3yjqn11NSWDWKtB9_JBfPPRyVUpzK1tfYTKfhdAcpDdvw@mail.gmail.com"
        type="cite">I'm working on the javAPRSlib parsers again, and I
        need a little help understanding the Q-constructs as injected by
        the APRS servers.
        <div>Here's a sample beacon:</div>
        <div><span class="raw_line"><b><a moz-do-not-send="true"
                href="http://aprs.fi/?c=raw&limit=&call=N0NPO-1">N0NPO-1</a></b>>APOT21,WIDE1-1,WIDE2-2,qAS,<a
              moz-do-not-send="true"
              href="http://aprs.fi/?c=raw&limit=&call=KC0WIF-1">KC0WIF-1</a>:!4422.30N/10023.30W>235/008/A=000593 13.7V  76F</span></div>
        <div><span class="raw_line"><br>
          </span></div>
        <div><span class="raw_line">So, this device is set to beacon to
            WIDE1-1, WIDE2-2.  According to Pete's q-Construct page:</span></div>
        <div><span class="raw_line"><b>qAS</b> - Packet was received
            from another server or generated by this server. The latter
            case would be for a beacon generated by the server. Due to
            the virtual nature of APRS-IS, use of beacon packets by
            servers is strongly discouraged. The callSSID following the
            qAS is the login or IP address of the first identifiable
            server (see algorithm).</span></div>
        <div><span class="raw_line">(<a moz-do-not-send="true"
              href="http://www.aprs-is.net/q.aspx">http://www.aprs-is.net/q.aspx</a>)</span></div>
        <div><span class="raw_line">I don't believe this is the "latter
            case", so what exactly has happened here?  Is this as simple
            as the IGATE KC0WIF-1 picking this packet up directly on the
            air and sending on to APRS-IS?  If that's the case, why
            isn't the qAR construct used?  is there a simple explanation
            of the difference, that I can put in my "APRS for Dummies
            and Naval Academy Graduates" notebook?</span></div>
        <div><span class="raw_line"><br>
          </span></div>
        <div><span class="raw_line">Thanks.</span></div>
        <div><span class="raw_line">John Gorkos</span></div>
        <div><span class="raw_line">AB0OO</span></div>
        <div><span class="raw_line"><br>
          </span></div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
aprssig mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>