[aprssig] Help with q-Constructs

[Lynn W. Deffenbaugh (Mr)]

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.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/16/2012 4:50 PM, Lynn W. Deffenbaugh (Mr) wrote:
> 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 
> http://www.aprs-is.net/qalgorithm.aspx (an invaluable reference, BTW, 
> if you can grok it):
>
>> All packets from an inbound connection that would normally be passed per current validation algorithm:
>> {
>> .... Non-applicable code removed....
>>      If a q construct exists in the header:
>>          Skip to "All packets with q constructs"
>> .... Not this one so....
>>      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...
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 5/16/2012 3:53 PM, John Gorkos wrote:
>> I'm working on the javAPRSlib parsers again, and I need a little help 
>> understanding the Q-constructs as injected by the APRS servers.
>> Here's a sample beacon:
>> *N0NPO-1 
>> <http://aprs.fi/?c=raw&limit=&call=N0NPO-1>*>APOT21,WIDE1-1,WIDE2-2,qAS,KC0WIF-1 
>> <http://aprs.fi/?c=raw&limit=&call=KC0WIF-1>:!4422.30N/10023.30W>235/008/A=000593 13.7V  76F
>>
>> So, this device is set to beacon to WIDE1-1, WIDE2-2.  According to 
>> Pete's q-Construct page:
>> *qAS* - 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).
>> (http://www.aprs-is.net/q.aspx)
>> 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?
>>
>> Thanks.
>> John Gorkos
>> AB0OO
>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120516/dccd1f71/attachment.html>