[aprssig] are write-only APRS-IS clients valid?

[Lee Bengston]

On Tue, Dec 3, 2013 at 6:54 AM, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

>
> On 12/2/2013 8:17 PM, Lee Bengston wrote:
>
>
>>  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?
>
> 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
> http://www.aprs-is.net/IGateDetails.aspx, emphasis mine):
>
>  Gate message packets and associated posits to RF if all of the following
> are true:
>
>    1. the receiving station has been heard within range within a
>    predefined time period (range defined as digi hops, distance, or both).
>    2. 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).
>    3. the sending station does not have TCPXX, NOGATE, or RFONLY in the
>    header.
>    4. the receiving station has* not *been heard via the Internet within
>    a predefined time period.
>    A station is said to be heard via the Internet if *packets from the
>    station contain TCPIP* or TCPXX* in the header* 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).
>
> 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.


> 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.
>

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).

>
> 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.
>

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.

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.

Thanks,
Lee - K5DAT

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