[aprssig] RE: Not Receiving Messages from APRS-IS (Pete Loveall AE5PL Lists)

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Jeff Kunce
> Sent: Monday, May 19, 2008 12:34 PM
> To: aprssig at lists.tapr.org
> Subject: [aprssig] RE: Not Receiving Messages from APRS-IS (Pete
> Loveall AE5PL Lists)
>
> When an igate send a message to RF, I'm sure it must signal other
> igates not to send that message anymore.  But I would think that it

Nope, nothing so elegant.  An IGate only knows about itself.  If a station it has heard within it "local" range (local defined by the IGate sysop and the IGate software) and someone sends a message to that station (an ack is just another message), the IGate will gate the message to RF.  The primary exception to that rule is if the station was also heard directly on APRS-IS (had TCPIP* in the path).  This can occur when someone is using a client like UI-View, Xastir, etc. connected to both RF and APRS-IS (most IGate configurations).

> would wait for an ack before it did that.  If an IGATE sends a message
> to RF,  can I track that event on findu et al?

No because it is gated to RF as a 3rd party packet which is blocked by APRS-IS (otherwise lots of looping which we saw in the past).

> I used WHO-IS as a simple example, but I also have problems getting
> acks from EMAIL and WLNK-1  I'll have to set up some skeds to see if
> plain old ham-to-ham messaging works.

This can also be caused by timing issues.  The original decay algorithm used in APRSDos can cause multiple copies of a message packet to appear to the digis and APRS-IS causing their sliding-window dupe timers (necessary for proper WIDEn-n operation and to prevent loops) to block the passage of those packets.  I believe the Kantronics digis use a 10 or 15 second sliding window and APRS-IS uses a 30 second sliding window.  The original decay algorithm predates the necessity for these dupe timers.

Have fun!

73,

Pete Loveall AE5PL
pete at ae5pl dot net